- changed component to FAPI2: Baseline
Shall require introspection of claims
FAPI 2 baseline says:
shall provide a means for resource servers to verify the validity, integrity, sender-constraining, scope (incl. authorization_details), expiration and revocation status of an access token, either by providing an introspection endpoint [RFC7662], by exposing signature verification keys, or by deployment-specific means
https://openid.net/specs/fapi-2_0-baseline-00.html#section-2.2.1-2.17.1
This should be updated to say:
shall provide a means for resource servers to verify the validity, integrity, sender-constraining, scope (incl. authorization_details and claims), expiration and revocation status of an access token, either by providing an introspection endpoint [RFC7662], by exposing signature verification keys, or by deployment-specific means
As an OpenID Connect profile, section 5 of core needs be handled as well.
Comments (20)
-
reporter -
The
claims
Authentication Request parameter requests that specific Claims be returned from the UserInfo Endpoint and/or in the ID Token.The claims parameter value itself should not IMHO be conveyed to resource servers at all. Its intent is authentication of the end user and subsequent identity claims being returned to the RP, not to pass through information to the RS.
Explicitly requiring introspection of the claims parameter value would only promote its miss use.
-
reporter Why would claims be limited to authentication? Maybe that’s how it is in the implementation you’ve used, but I’ve never read that in any spec. If authorization_details is included then so must claims be, as applicable.
Cf. https://datatracker.ietf.org/doc/html/draft-spencer-oauth-claims-01#section-2.3
-
- changed status to open
Related to
#417. To be continued. -
reporter Cf. https://datatracker.ietf.org/doc/html/draft-ietf-oauth-access-token-jwt#section-2.2.1 and https://datatracker.ietf.org/doc/html/draft-ietf-oauth-access-token-jwt#section-2.2.2 where it says (among other things) that:
Any additional identity attribute whose semantic is well described by an entry in the JSON Web Token (JWT) IANA registry introduced in [RFC7519] SHOULD[1] be encoded using the corresponding claim name, if that attribute is to be included in the JWT access token. Note that the JWT IANA registry includes the claims found in Section 5.1 of [OpenID.Core].
A lot of the discussion in this and Issue
#416has been around authorization, so I’d like to also draw the group’s attention to https://datatracker.ietf.org/doc/html/draft-ietf-oauth-access-token-jwt#section-2.2.3.1 that says:Many authorization servers embed in the access tokens they issue authorization attributes…. An authorization server wanting to include such attributes in a JWT access token SHOULD[1] use as claim types the "groups", "roles" and "entitlements" attributes of the "User" resource schema defined by Section 4.1.2 of [RFC7643]).
So, my question to this group is: without the clarification I proposed above, how is an authorization server expected to conform to FAPI 2 baseline and this OAuth working group draft once it’s an RFC? That seems unclear at best with the current wording, and should be clarified by my recommended addition.
[1] SHOULD here meaning “there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.” from https://www.rfc-editor.org/rfc/rfc2119.html
-
I don’t see any conflict between FAPI2 and the JWT Access Token draft.
My understanding is:
- JWT Access Tokens if they contain identity claims should use the registered claim names
- JWT Access Tokens can include authorization attributes, if they do so, they should ideally follow SCIM
JWT Access Tokens shouldn’t change any semantics of OAuth 2 or OIDC.
If an implementer is using FAPI 2 and RAR and https://datatracker.ietf.org/doc/html/draft-ietf-oauth-access-token-jwt#section-2.2.3.1
Then it seems that they should represent authorized RAR details in a SCIM format in the JWT access token?
Am I missing something?
-
I would suggest moving the word claims to stand on its own as the claims of the token and not implying claims are somehow subordinate to scope. Like this perhaps:
shall provide a means for resource servers to verify the validity, integrity, sender-constraining, scope (incl. authorization_details), claims, expiration and revocation status of an access token, either by providing an introspection endpoint [RFC7662], by exposing signature verification keys, or by deployment-specific means
-
I concur with @Brian Campbell
-
reporter As discussed on the WG meeting today, the
and claims
suggested addition here has nothing to do with:- The claims request parameter (from section 5.5 of OIDC core https://openid.net/specs/openid-connect-core-1_0.html#ClaimsParameter)
- The claim names included in the introspection response set forth in section 2.3 of https://datatracker.ietf.org/doc/html/draft-spencer-oauth-claims-01 (that was mentioned above as a counter point a point Philip was making and wasn’t meant to confuse with the original suggested text)
The
claims
here is the term used in https://datatracker.ietf.org/doc/html/draft-ietf-oauth-access-token-jwt and defined in section 2 of RFC 7519 https://www.rfc-editor.org/rfc/rfc7519.html#section-2 -
- changed milestone to 2nd Implementers Draft
-
Account Deactivated There is no harm to add claims as element that will be validated by these means that shall be made available to RS. I agree that it needs to be clear that it is not intention of this specification to make claims some sort of scope subcomponents.
The revised text in Brian’s comment looks fine to me. If we decide to add it to the specification, we shall consider adding language to express what @Travis Spencer summarised in his last comment, so that it is explicit what claims we are referring. So far we haven’t used “claims” anywhere in the document.
@Travis Spencer I think you have wrong reference under JWT profile link. It should link to https://datatracker.ietf.org/doc/html/draft-ietf-oauth-access-token-jwt and not to 2.2.1 Authentication Information Claims. Correct?
-
Account Deactivated Since we are unpacking this item about availability of these means to RS. I wanted also to draw the group’s attention to two more things:
- There is reference to the introspection endpoint RFC there, but we don’t have such reference for the other means
by exposing signature verification keys, or by deployment-specific means
Shall we add reference to https://datatracker.ietf.org/doc/html/draft-ietf-oauth-access-token-jwt-13#section-4 ?
2. This sentence also logically says that exposure of “signature verification keys” can be considered a tool to check “revocation status”.
shall provide a means for resource servers to verify (…) revocation status of an access token, either by providing an introspection endpoint [RFC7662], by exposing signature verification keys, or by deployment-specific means
If it gets some traction here I’ll create separate issue for that.
-
Regarding Brian’s proposal:
shall provide a means for resource servers to verify the […] claims […] of an access token,
What are the claims of an access token?
I’m not sure what the RS would verify here.
-
I concur with Brian’s proposal, I think it’s an acceptable change.
Regarding Daniel’s question “What are the claims of an access token” I can refer to the definition in https://www.rfc-editor.org/rfc/rfc7519.html#section-2
Claim
A piece of information asserted about a subject. A claim is
represented as a name/value pair consisting of a Claim Name and a
Claim Value.
I.e. any asserted name/value in the access token. This is used in many systems to convey information about the subject to the API. It can be anything that is relevant to help the API make an authorization decision. I’ve noticed that the OpenID/OAuth community often confuses claim with the input parameter called claim. Whereas we at Curity most often mean claim in the sense defined above (and how it’s been traditionally used in other protocols before JOSE).
So, to sum up: I suggest we go with Brian’s proposal, which include claims as something the RS may use when validating the token and its access.
-
Dave & I talked about this and we propose removing this clause entirely. It’s not testable and AS ↔︎ RS communication isn’t really in scope for FAPI.
-
removing this clause entirely makes sense too
-
-
assigned issue to
-
assigned issue to
-
-
- changed status to resolved
PR merged
-
- changed component to FAPI2: Security Profile
- Log in to comment