Shall require introspection of claims

[Travis Spencer]

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.

[Filip Skokan]

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.

[Travis Spencer]

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

[Nat Sakimura]

Related to #417. To be continued.

[Travis Spencer]

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 #416 has 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

‌

[Dave Tonge]

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?

‌

‌

[Brian Campbell]

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

‌

[Filip Skokan]

I concur with @Brian Campbell

[Travis Spencer]

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

[Lukasz Jaromin]

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?

‌

[Lukasz Jaromin]

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:

1. 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.

[Daniel Fett]

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.

[Jacob Ideskog]

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.

[Joseph Heenan]

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.

[Brian Campbell]

removing this clause entirely makes sense too

[Dave Tonge]

https://bitbucket.org/openid/fapi/pull-requests/310/withdraw-clause-re-introspection

[Dave Tonge]

PR merged