No, client id_are scoped by issuer. There is no need for AS to make the client_id globally unique.
The client needs to not allow two AS to provide it with the same issuer client_id pair. That would probably be imposable for many clients anyway. For Connect clients typically manage configurations using issuer as the primary key. I doubt may would support even two client_id from the same issuer. For OAuth what clients do is slightly less clear. In general they don’t have more than one AS per API do might try and organize things by RS or AS. In principal a OAuth client might have two different AS each with a different client ID and that will be OK as long as the client_id in the request is the same as the one in the response. So going to a new AS and getting back the same iss and client_id that you registered someplace else would be an error for the client. I don’t think that is unreasonable. John B. > On Jan 25, 2016, at 12:30 PM, George Fletcher <gffle...@aol.com> wrote: > > I'm still catching up... but to this point specifically... > > Doesn't this require that the same client_id NOT be used simultaneously at > two (or more) Authorization Servers? If so, I don't believe that is a viable > option. It's a little late in the game to be putting requirements on the AS > as to how it generates it's client_id. > > Thanks, > George > > On 1/25/16 9:11 AM, John Bradley wrote: >> >> Returning the iss and client_id from the authorization endpoint per Mike’s >> draft allows the client to reject the authorization response and not leak >> the code. >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
