RAR if scope *and* claims param not expressive enough

[bitbucket-import-issues]

Originally submitted by Travis Spencer (Travis Spencer) on 2021-05-28

I’m reviewing FAPI 2 baseline, and noticed this in 2.2.1 point 7:

shall support the authorization_details parameter according to [I-D.ietf-oauth-rar] to convey the authorization clients want to obtain if the scope parameter is not expressive enough for that purpose

This should say “…to convey the authorization clients want to obtain if the scope and claims parameters are not expressive enough for that purpose”

‌

---

Bitbucket status: resolved

Bitbucket origin: issue 416

[bitbucket-import-issues]

Originally submitted by Ralph Bragg (Ralph Bragg) on 2021-05-28

I’m not sure I agree with the proposed wording behind this issue or at least it’s worth a bigger debate. OBIE miss used the claims parameter to pass a reference to a fine grained scope resource. It was all that was available at the time. Resource access should be controlled by Scope even if it is used to convey a reference (in the absence of support For Authorization details - rar).

There is another related ticket on this clause as the lodging intent pattern actually offers more flexibility for complex resources that is only solved by requiring grant management api as a replacement.

personally I would like too see a clause that says the claims parameter should be only used as intended to convey information the authenticating user and not used to request resource access scope.

[bitbucket-import-issues]

Originally submitted by Travis Spencer (Travis Spencer) on 2021-06-02

This spec needs to work with other OpenID Connect profiles. Core has been widely deployed, there are many certifications, and much momentum behind it. Your mention of what OBIE, for instance, shows that the flywheel is running. As spec authors and members of the foundation, we have a duty to be cognizant of the impact this new spec has on the ecosystem.

Claims is part of core. There is nothing in core or any other OpenID Foundation, IETF document, or other standards body’s spec/draft that says that claims are for authentication only. That notion was expressed in #417 by Filip Skokan . I really don’t understand the genesis for that idea because I’ve never read it in any spec. In fact, I hold the contrary view which is codified in that draft I-D I mentioned in #417. So the inclusion of this debatable “intent” about the nature of the claims param being for auth (that isn’t written down anywhere that I know of at least) is not befitting of a spec design to foster interoperability. What is is the clause I suggested.

[bitbucket-import-issues]

Originally submitted by Ralph Bragg (Ralph Bragg) on 2021-06-02

it’ll be interesting to get other peoples view on this, i wasn’t aware of Filip Skokan ticket but i do agree with his point of view.

https://openid.net/specs/openid-connect-core-1_0.html#Claims

5.  Claims

This section specifies how the Client can obtain Claims about the End-User and the Authentication event. It also defines a standard set of basic profile Claims. Pre-defined sets of Claims can be requested using specific scope values or individual Claims can be requested using the claims request parameter. The Claims can come directly from the OpenID Provider or from distributed sources as well.

I read this is as pretty black and white that claims are meant to be used to describe information ‘about the end-user’ and the ‘authentication process’ as its primary purposes not as a means of conveying requests to a fine grained Authorization for resources. It was a mechanism that Pam Dingle and I new technically could be made to work for the OBIE security profile but it was acknowledged at the time that it was questionable as a means of controlling access to resources.

This clause also explicitly says that scopes can be used to request claims, there is no reference at all to claims being used to ‘scope access to resources’.

I don’t believe that there is any issue or compatibility issues with core with the clause. In addition, this profile has a primary aim to standardise and solve privacy and complex Authorization concerns. If implementers want to ‘just use a secure profile’ they can stay on FAPI 1 and enable all of the optional features (PAR, Encrypted Request Objects) etc but one of the goals of the foundation is to promote global interoperability and so far there isn’t a standard explicitly targeting privacy and fine grain authorisation standardisation which is a major goal of FAPI 2 + Grant Management.

This goal was re-articulated in the recent Australian and Brazillian workshops from the WG.

Great topic to debate and reaffirm what the primary goals are of FAPI 2 and if this is something that we want to carry forward.

[bitbucket-import-issues]

Originally submitted by Renato Athaydes (Renato Athaydes) on 2021-06-02

The Core OpenID Specification makes use of scopes as a collection of claims, as described in https://openid.net/specs/openid-connect-core-1_0.html#ScopeClaims .

The "claims" parameter can therefore be seen as a more fine-grained "scope" parameter. This is a great idea!

In real-world applications, it's common to see people creating their own ad-hoc hierarchies using only scopes (i.e. stringly-typed trees), when if the concept of claims were extended also to authorization (rather than limited to authentication and end-user information), it could make things much better.

Travis Spencer has submitted a draft RFC that does that. I am not sure why you believe doing that is mis-using the "claims" parameter. It's just giving people more options when it comes to requesting finely-grained authorization claims than scope can provide.

Having a concept such as "claims" that is so general, while keeping it so limited in usage, doesn't seem to make more sense than extending its applicability.

The “authorization_details” parameter seems to aim for almost exactly the same thing as “claims” does in the context of ID tokens, while introducing a whole new specification just to make things a little bit more convenient, while having significant overlap (e.g. see the “read” and “write” examples in the spec) with the concept of scopes (“claims” is powerful enough as described in OpenID Core to achieve basically everything “authorization_details” does).

technically could be made to work for the OBIE security profile but it was acknowledged at the time that it was questionable as a means of controlling access to resources.

I wouldn’t agree with this. Could you provide a link to the discussion where this was debated? It would be interesting to see how the points of debate apply to “authorization_details”.

[bitbucket-import-issues]

Originally submitted by Nat (Nat Sakimura) on 2021-06-02

Long discussion on the June 2 call.
The discussion to be continued.

[bitbucket-import-issues]

Originally submitted by tlodderstedt (Torsten Lodderstedt) on 2021-06-02

Just to inform the discussion: Travis proposed https://datatracker.ietf.org/doc/html/draft-spencer-oauth-claims-01 (which expired in the meantime) as alternative to RAR. There was an extensive discussion in the OAuth WG. As a result, the OAuth WG decided to adopt RAR.

[bitbucket-import-issues]

Originally submitted by Renato Athaydes (Renato Athaydes) on 2021-06-02

I was under the impression that the only difference between “claims” and the newly proposed “authorization_details” is syntax. They both can be used to do the same thing, i.e. influence what their target token will contain (assuming you accept that the OIDC “claims” parameter could be used for the “access_token” as well).

In the discussion we had today, some people appeared to express that the two things are very different, even that using “claims” for this would break some separation of concerns between the AS and the client and the RS (from what I understood). I would be curious to know what exactly is the difference and what concerns were being referred to, hope someone can explain to me as I think I am missing something important here.

[bitbucket-import-issues]

Originally submitted by tlodderstedt (Torsten Lodderstedt) on 2021-06-02

assuming you accept that the OIDC “claims” parameter could be used for the “access_token” as well

That’s the important point. The OIDC claims parameter determines the claims shared between OP and RP via id token or userinfo. Using it to determine the claims in an access token has significant consequences:

The client needs to know what claims the RS needs to perform a certain action(s) and what claims will cause the RS to allow this action(s). This breaks the encapsulation of the interface between the AS and the RS. Suppose the RS needs more user data in a new revision, all clients needs to be notified and updated to request the right claims set in order to be able to access. Really?

I prefer a model where the client asks for certain permissions (I wanna sign a document) and the AS knows what data to put in the access token for a particular RS in order to make that happen (name, dob and so on for respective user). This makes sense since the AS’s job is to protect RSs, which also means the AS knows its RSs. The implementations I know map scope values (or authorization details) to token content based on policies.

‌

[bitbucket-import-issues]

Originally submitted by Renato Athaydes (Renato Athaydes) on 2021-06-02

Torsten Lodderstedt Thanks for your answer. Let me see if I understand.

The client needs to know what claims the RS needs to perform a certain action(s)…

This breaks the encapsulation of the interface between the AS and the RS.

I prefer a model where the client asks for certain permissions (I wanna sign a document) and the AS knows what data to put in the access token for a particular RS in order to make that happen

Ok, so the difference between asking for certain claims to be added to the token, and asking for some abstract permissions that somehow maps to whatever the RS uses to authorize (let’s call that C) is that in the former, the mapping between how the client asks for permission and how the RS evaluates that is direct, and in the latter, the mapping is completely unspecified?

But at the end of the day, C is going to be one or more claims (in the access token) for each of the authorizations that were requested. And if those authorizations look like in the specification for “authorization_details”, I fail to see how they won’t actually map 1-1 to actual claims in the token. And those claims are always specific to a particular RS, it’s not like a token’s claims and C are independent (which you seem to be saying is a desirable property of the system).

I would say that when an AS sees this “authorization_details” parameter:

‌

{
      "type": "payment_initiation",
      "locations": [
         "https://example.com/payments"
      ],
      "instructedAmount": {
         "currency": "EUR",
         "amount": "123.50"
      },
      "creditorName": "Merchant123",
      "creditorAccount": {
         "iban": "DE02100100109307118603"
      },
      "remittanceInformationUnstructured": "Ref Number Merchant"
   }

There’s no possible scheme that an AS can come up with to evaluate this (against some policy) that is completely independent of C. It could be helpful if you could show what C should look like in this case for the systems you are familiar with, if not basically copying most if it into the access token itself (which is almost what we do with the “claims” parameter, subject to transformations our server supports), and what advantage, for the client, there would be in not knowing C directly. Isn’t C one layer of abstraction we don’t really need here? To me, this is exactly the kind of information I would like to have on my backend, after reading the presented JWT.