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

[Sarah Squire]

Throughout

we should probably use example.com in our examples rather than 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20151128/3251fb50/attachment-0001.html>