Hi Dick, I like the draft! It puts together some best practices relevant for dynamic OAuth in a reasonable way.
Some comments: Section 2: I appreciate the idea to let the resource determine its resource URI (later used as aud of the access token). This will allow the RS to segment and group its resources as needed. 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. 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? I would desire support for an integrated UI flow for authorizing access to multiple resources at once. This makes sense in multi-service deployments. 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. 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
