[Openid-specs-heart] Review of OAuth security profile

Wed Dec 2 01:57:50 UTC 2015

Thanks for the thorough review. I’ve just finished incorporating pretty much all of these suggestions, apart from the speculation on what might be desirable in iGov. We’ll leave things as they are now, which is an understood deployment pattern, and have to figure out how it fits or doesn’t in iGov.

 — Justin

> On Nov 28, 2015, at 12:44 PM, Sarah Squire <sarah at engageidentity.com> wrote:
> 
> Throughout
> we should probably use example.com <http://example.com/> in our examples rather than mitre.org <http://mitre.org/>
> OAuth flow terms are sometimes wearing spanx and sometimes not; let’s be consistent.
> 
> 1. 
> “for use in the context of securing Representational State Transfer (RESTful) interfaces” is it for the context of restful apis? or is it (at least right now) for the context of healthcare?
> 
> 2.1.2 
> “SHOULD be tied to the user’s authentication session with the client” what do we mean by “tied to”? Perhaps we should say “SHOULD expire when the user’s authentication session with the client expires”
> 
> 2.2 
> We don’t have to spell out and reference JWT here; we already did that in 1.2.
> The iss, aud and sub fields may be problematic in potential iGov implementations requiring blinded parties and/or an intermediate bridge.
> 
> 2.3 
> errant “in”: “from a web-based client to the end user’s browser in for the purpose of redirecting” should be “from a web-based client to the end user’s browser for the purpose of redirecting” 
> 
> 3.
> All instances of jwks and jwks_uri should be wearing spanx here.
> “allows for key rotation more easily” is awkward. Perhaps “allows for simpler key rotation”
> This is the first reference to JWK or JWKS. They should be spelled out and referenced.
> 
> 3.1
> We need to spell out and reference TLS
> 
> 
> 3.2 
> Dynamic Client Registration Protocol is no longer “draft” (yay!) and the RFC should be referenced here
> 
> 4. 
> Should we put in here somewhere that the server must also validate the jwks_uri if one has been provided?
> 
> 4.1 
> This is the first time we talk about either introspection or revocation. We should provide a reference to the relevant RFCs.
> No need to spell out JWKS, as it first appears in Section 3.
> This says “OpenID Connect Provider” I think most people say “OpenID Provider.” 
> We should link to the reference for the HEART OpenID Connect Profile when we mention it.
> 
> 
> 4.2 
> iss, azp and sub may interfere with attempts to blind systems from each other and/or blind them to the identity of the user in potential iGov applications.
> No need to spell out JWS, we did that in 1.1.
> No need to reference JWE, we did that in 1.1.
> 
> 4.4 
> This seems to repeat a lot of information that is already contained in the introspection RFC. We should probably cut that and just reference it.
> 
> 5. Awkward wording: Change “One mechanism for doing this is by querying the scopes” to “This can be accomplished by querying the scopes”
> Should we also require that the protected resource check that the token hasn’t expired?
> 
> 5.1 The statement “the client MUST authenticate using a JWT assertion” is contradicted by the next sentence “A protected resource MAY allow a client to authenticate using mutual TLS, either in lieu of or in addition to the JWT assertion.” I would rewrite:
> 
> “Normally when using an OAuth bearer token, the client does not separately authenticate to the protected resource. However, some protected resources in high value environments MAY require the client to authenticate to the protected resource in addition to presenting an access token. When authenticating to such protected resources, the client MUST use either a JWT assertion signed with its private key as described in Section 2.2, mutual TLS, or both. In such cases, a protected resource MUST verify that the identifier of the client is included in the “azp” field (authorized presenter) of the access token.”
> 
> 7. 
> What is “The preceding OAuth profiles” referring to? Perhaps “The preceding portions of this profile” would be better?
> 
> 7.1 
> Awkward wording. I would rewrite: “Stronger client authentication to the protected resource, combined with validating that the authenticated client is the one to which the token was issued through the azp token claim, reduces the risk of captured tokens being used by unauthorized clients.”
> 
> “Stronger client authentication to the protected resource, combined with validation that the authenticated client is identified in the azp token claim, reduces the risk of captured tokens being used by unauthorized clients. “
> 
> References
> JWA is now RFC 7518
> JWE is now RFC 7516
> JWK is now RFC 7517
> JWS is now RFC 7515
> JWT is now RFC 7519
> OAuth.Registration is now RFC 7591
> Add references to RFC 7662 and RFC 7009 (introspection and revocation)
> 
> Sarah Squire
> Engage Identity
> http://engageidentity.com <http://engageidentity.com/>_______________________________________________
> Openid-specs-heart mailing list
> Openid-specs-heart at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-heart

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20151201/0c218627/attachment.html>