Require explicit authentication methods - spec & code update about openyolo-android HOT 3 CLOSED

Your reasoning makes sense, and I have seen a few practical examples where the authentication methods varied by platform for a service - for instance, supporting Google Sign-in on Android only. Such variation is usually disastrous though, as you end up locking users out of their accounts when they switch platforms :/

Playing it safe from our perspective and always requiring an app be explicit about the auth methods they support is probably the best course of action for now. So, sounds like this issue now becomes "remove wildcard behavior from spec".

from openyolo-android.

I think it would probably be better to just make the proto field optional, rather than having a "special" auth method value that could be accidentally mixed with other values.

from openyolo-android.

Maybe there is not a compelling reason to support this wildcard? Assumption: From my understanding the client application should always authenticate the retrieved credential therefore a retrieved credential with an unknown authentication method would be of no use to the client.

To avoid this possible scenario the client should only retrieve credentials with supported authentication methods.

Now that I think about this a wildcard seems like an opportunity for clients to potentially shoot themselves in the foot. For example I can imagine the following scenario where an app developer completes their android implementation using a wildcard for authentication method while their client only supports authentication method A, the developer adds a web frontend which supports authentication methods A and B, additional credentials are now available for unsupported authentication method B. Now the android application may receive unsupported credentials which may or may not be accounted for by the developer's implementation.

Additionally this wildcard is set as the default value when using the RetrieveRequest.Builder. If there is a reason to support it I suggest it is changed to an non-default value to help developers avoid the situation described above.

from openyolo-android.