Hi Dick, > >> >> Section 3: >> Don’t you think it could be a useful information to have the resource URI >> available in the authorization flow?I would assume it could have some >> additional meaning to the AS and could also be the context of the scope. > > I'm assuming you are referring to the Authorization Code Grant. Good call out > that the resource URI would be useful in the redirect. > > The use cases that I have been working with have all been Client Credential > Grants > > I currently don't know of a real world use case for the Authorization Code > Grant for Distributed OAuth.
I think any scenario with multiple resource servers relying on the same AS for authorization where the client acts on behalf of the resource owner qualifies for grant type code and distributed OAuth. Let’s assume a user wants to authorize a client for access to her cloud storage, email account and contacts when setting app the respective app. One would use the code grant type for that use case. And having the resource URLs in the authorization flow would allow the AS to further determine the context of the requested authorization. Even more important, the AS could restrict the access tokens for use at this URIs only. At best, the AS would allow the client to obtain different access tokens for any of the involved resource servers, each of them tailored to the needs of the particular RS (content) and bound to it (aud, token binding, ...). In the YES context, we have several different services/resources, which can be combined in a single authorization transaction, e.g. initiation of a payment and creating an electronic signature. In all solutions I have seen or designed in the past, the resource server was either carried in the scope parameter or implicitly determined from the scope values (see OIDC). Making it explicit would result in an interoperable approach to represent this information and use it to tighten up OAuth security and privacy (token binding, audience restriction). kind regards, Torsten. > >> >> Section 4: >> I think the client MUST authenticate using a PoP (asymmetric crypto based) >> mechanisms due to the attack angle given in 6.3 >> Did you intentionally restricted the draft to single resources? > > yes > >> I would desire support for an integrated UI flow for authorizing access to >> multiple resources at once. This makes sense in multi-service deployments. > > It could be. Would be great to get some real use cases for that in an > Authorization Code Grant. > >> >> Section 6.1. >> I suggest you also refer to >> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-06#section-3.7 >> for a comprehensive discussion of this threat.. > > Thanks > >> >> kind regards, >> Torsten. >> >> >> > Am 12.06.2018 um 21:28 schrieb Dick Hardt <dick.ha...@gmail.com>: >> > >> > Hey OAuth WG >> > >> > I have worked with Nat and Brian to merge our concepts and those are >> > captured in the updated draft. >> > >> > https://datatracker.ietf.org/doc/draft-hardt-oauth-distributed/ >> > >> > We are hopeful the WG will adopt this draft as a WG document. >> > >> > Any comments and feedback are welcome! >> > >> > /Dick >> > _______________________________________________ >> > OAuth mailing list >> > OAuth@ietf.org >> > https://www.ietf.org/mailman/listinfo/oauth >> >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
