So now, in addition to the dynamic client registration spec, the client
would need to support OAuth2 Discovery.
I guess my concern is that it feels like we are adding a lot of little
things to try and mitigate these attacks in OAuth2 and it's confusing
when they are needed and when they aren't.
For me it would be simpler to say that OAuth2 with a single
pre-configured AS is fine. If a client wants to support multiple
Authorization Servers (a la dynamic client registration or some other
method) then here are all the things that need to be done. Maybe this
would be simpler as a profile of OAuth2 (in the vein of OpenID Connect)
that adds the necessary requirements to mitigate these attacks.
This way an OAuth2 developer knows which spec to follow based on their
requirements and all the necessary steps would be in "one" place.
Thanks,
George
On 1/25/16 1:22 PM, John Bradley wrote:
The presumption is that registration would need to add a issuer, as an
identifier of the AS, and that would be optionally be used in discovery.
OAuth as is supports the single AS model.
To support multiple AS for a single client something needs to change.
Adding issuer and client_id to the response with optional discovery
was seen as the least disruptive at the Germany meeting.
The other way to do it is to return discovery info from the the
authorization and token endpoints, however the request probably also
need to be modified so that the AS knows what the resource is, otherwise
other things will break.
It is possible now to have one authorization endpoint provide code for
per Tennent token endpoints.(No I don’t know of any one doing it).
Anything we add to tighten up the trust model will have impacts on
what can be done with OAuth.
John B.
On Jan 25, 2016, at 3:10 PM, George Fletcher <gffle...@aol.com
<mailto:gffle...@aol.com>> wrote:
Comments inline
On 1/25/16 12:32 PM, John Bradley wrote:
No, client id_are scoped by issuer.
This makes sense, but I'm not sure it's a current assumption by
OAuth2 implementations :)
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.
I would rather say that the results of two client_ids being the same
from two different issuers is undefined.
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.
If scoped by issuer this makes sense, though the concept of "issuer"
as a comparable entity wasn't really talked about with OAuth2.
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.
I agree that not many clients support dynamic client registration.
However, I would say there a number that support multiple AS that are
"fixed" within the code (including fixed endpoint URIs). So I would
say that the associations would be fixed in code. There wouldn't
necessarily be an association outside of the code which maps button A
to AS1 and button B to AS2.
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.
I agree that this is reasonable with the assumption that client_id's
are scoped by "issuer". It's just likely that most clients in the
field do not have this sort of explicit association. The OAuth2
Dynamic Client Registration spec does not define an "issuer" in the
response. For the OAuth2 use cases, what is the proposed "issuer"
equivalent URI that is being used to scope the client_id?
John B.
On Jan 25, 2016, at 12:30 PM, George Fletcher <gffle...@aol.com
<mailto: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.
--
Chief Architect
Identity Services Engineering Work:george.fletc...@teamaol.com
AOL Inc. AIM: gffletch
Mobile: +1-703-462-3494 Twitter:http://twitter.com/gffletch
Office: +1-703-265-2544 Photos:http://georgefletcher.photography
--
Chief Architect
Identity Services Engineering Work: george.fletc...@teamaol.com
AOL Inc. AIM: gffletch
Mobile: +1-703-462-3494 Twitter: http://twitter.com/gffletch
Office: +1-703-265-2544 Photos: http://georgefletcher.photography
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
