1. OpenID Foundation Avatar OpenID Foundation
  2. WGs
  3. fapi
  4. Issues

RAR if scope *and* claims param not expressive enough

Issue #416 resolved
Travis Spencer created an issue

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”

‌

Comments (29)

  1. Ralph Bragg

    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.

  2. Travis Spencer reporter

    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.

  3. Ralph Bragg

    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.

  4. Renato Athaydes

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

  7. Renato Athaydes

    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.

  8. Torsten Lodderstedt

    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.

    ‌

  9. Renato Athaydes

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

  10. Tom Jones

    For better or for worse OpenID Connect claims are, at a minimum, indicative of IAL, AAL and FAL (with federation). The entire (original) point of KYC was identity proofing and that is a major consideration as well.

  11. Torsten Lodderstedt

    @Renato Athaydes The question is not whether the AS conveys the data as being requested by the client to the RS. The question is what the client asks for. claims means to ask for user claims. authorization_details means to ask for permission to do something.

    The example you gave illustrates the difference pretty good. The client wants to perform a payment initiation, so the authorization details contain data of this payment initiation transaction. The request does not request any user claims to be put in the respective access token because the client just does not care about it. If approved, the information about the approved payment initiation is conveyed to the RS along with additional data added by the AS, including user claims.

    The following example (from https://datatracker.ietf.org/doc/html/draft-ietf-oauth-rar#section-9) shows how the corresponding access token content for this example might look like. 

       {
      "iss": "https://as.example.com",
      "sub": "24400320",
      "aud": "a7AfcPcsl2",
      "exp": 1311281970,
      "acr": "psd2_sca",
      "txn": "8b4729cc-32e4-4370-8cf0-5796154d1296",
      "authorization_details": [
         {
            "type": "https://www.someorg.com/payment_initiation",
            "actions": [
               "initiate",
               "status",
               "cancel"
            ],
            "locations": [
               "https://example.com/payments"
            ],
            "instructedAmount": {
               "currency": "EUR",
               "amount": "123.50"
            },
            "creditorName": "Merchant123",
            "creditorAccount": {
               "iban": "DE02100100109307118603"
            },
            "remittanceInformationUnstructured": "Ref Number Merchant"
         }
      ],
      "debtorAccount": {
         "iban": "DE40100100103307118608",
         "user_role": "owner"
      }
   }

    You see the AS added not only the “sub” but also a “user_role” claim, which conveys the role/privileges the respective user has with respect to the selected debtor account. Those claims are part of the contract between AS and RS, the client does not need to know.

  12. Dave Tonge

    I agree with Ralph and Torsten that OIDC core is clear on the use of claims as:

    This section specifies how the Client can obtain Claims about the End-User and the Authentication event.

    In some current deployments claims have been used for a different means, but this is not how they are defined.

    In FAPI 1.0 we also used elements of OIDC to provide additional security, however this has also caused confusion.

    OIDC at its heart is about identity. In FAPI 2.0 we are keen to allow Authorization Servers that don’t want to touch identity to provide secure services without needing to use OIDC.

    For this reason (and because FAPI 2 has primary aim of interoperability) I’m strongly in favour of the existing text.

    Existing products have 3 options:

    1. Don’t support FAPI 2
    2. Support FAPI 2 but just with scopes
    3. Support FAPI 2 with RAR

    I propose that this issue is closed

    ‌

  15. Renato Athaydes

    The question is what the client asks for. claims means to ask for user claims. authorization_details means to ask for permission to do something.

    The word “claim” is used throughout OAuth and related specifications to refer to objects used for authorization (including, but not limited to, “scope”), so I have to disagree strongly with this sentence.

    The RAR spec has this to say (8.1):

    If the access token is a JWT [], the AS is RECOMMENDED to add
   the "authorization_details" object, filtered to the specific
   audience, as top-level claim.

    I.e. authorization_details is a claim. This is how I view the word “claim” and this is perfectly in line with that (even if not directly describing something about the user, but about what a user can do).

    This, however, goes against saying claims means to ask for user claims unless you limit yourself to a non-normative phrasing of the OIDC specification, and you mean specifically the “claims” parameter as defined in OIDC, not just the word “claims” in general.

    While I agree it might be possible to map the claims inside authorization_details to something unlike what the client has requested, I believe, based on experience, that trying anything else will quickly lead to extremely complex mappings which are almost guaranteed to not be worth the perceived benefits of de-coupling authorization request from the shape those permissions will take. Not to mention clients are already intrinsically coupled to the RS by definition. I would think prescribing such overly complex mappings is a non-goal of FAPI 2, but with the current phrasing, defining that kind of mapping becomes mandatory, while decreasing interoperability given that the mapping itself is left for each implementation (hence, the de-coupling is illusory).

    You see the AS added not only the “sub” but also a “user_role” claim

    Requesting certain claims does not preclude the addition of others, or the grant of different values in certain cases, so this is also possible (and standard even) with our current implementation based on the “claims” parameter. You could almost replace “claims” with “authorization_details” without significantly changing much.

  17. Jacob Ideskog

    I do not agree that we can close this ticket, it has yet not been discussed and I feel there is confusion about the topic.

    I agree that OpenID Core aimed to use Claims for identity purpose and I think, decoupling FAPI 2.0 from OpenID Connect may be a good idea. However, regarding the Claims issue some thoughts came into my mind:

    1.) Yes, OpenID Core introduced the claims parameter to enable clients to request certain user claims in the ID token or user_info response. It is legit to extend this definition in complementary specifications. This is how the whole framework works. Taking that into account a specification (or draft of it) can introduce the claims parameter for OAuth aka access tokens as well. Then it is not a OpenID Core question anymore and fully in line with FAPI 2.0.

    2.) There is a contract between the client and RS as well. The client needs to know how to call the API, the expected input and output. Even though a client "does not need to know about the claims" in the final access token, the ability to request such claims may improve the flow. If the client requests to add a certain claim to the access token, the AS may always just ignore any such claims-request, add, remove or modify claims in order not to break the contract with the RS. In the example mentioned above, 'primary account' can be considered an identity claim. The client could have requested to add the user's 'primary account' to the access token using the claims parameter. As a result, the user does not have to select the 'debtorAccount'. This would improve user experience.

    So, IMHO the general aversion of not having the client requesting claims for the access token through the claims-parameter is not justified. I even state that you can use authorization_details and the claims parameter (for access tokens) side by side as outlined in point 2. Regardless of how extensively some implementations may use (or misuse) the claims-parameter for fine grained authorization, in general it makes sense to have the client request claims for the access token and thus the proposed wording is reflecting a valid concern.

    ‌

  18. Dave Tonge

    I think we are conflating the claims parameter from OIDC and JWT claims (RFC7519).

    Claims in a JWT are simply signed values communicated between 2 parties.

    The use of the claims parameter in OIDC is very clearly to enable the Client to request claims about the user from the AS (whether in a JWT or an API response).

    JWTs are widely used in the OAuth ecosystems and contain many types of claims. However there is no set way for a Client to request claims to be put in an access token (indeed access tokens are often not JWTs and should be opaque to the Client).

    The questions I have @Jacob Ideskog are:

    1. There is no specification on a standards track that allows the claims parameter to be used to convey rich authorization data. Do you agree that this is the case?
    2. You seem to suggest that an AS could gain consent for a user without understanding the nature of the authorization being requested and then simply pass on authorization data to the RS - I think this is dangerous and that the AS must clearly understand and allow the user to clearly consent to the particular authorization being requested. Have I misunderstood you?

    ‌

  19. Jacob Ideskog

    I may sound conflated but it is not. The claims parameter guides what claims the client requests, it is up to the AS/OP to decide what goes in to which token. JWTs are far from the only tokens that carry claims, SAML tokens, and even opaque tokens carry claims if trust is setup in any fashion. Signing is one way. The content of any token with established trust can be considered claims if done right. Claims predate both OAuth and OpenID as concepts which is why they should no be easily disregarded in this context.

    1. The OpenID Core specification is enough. The claims parameter is rich, and by having the FAPI 2 spec define what claims must be supported the problem is solved. Alternatively the work on the claims spec (https://datatracker.ietf.org/doc/html/draft-spencer-oauth-claims-01) could be picked up again which is less intrusive than RAR. But in short words, requesting authorization_details should definiately be considered as a claims request for the authorization_details claims wich can be a structured claim.
    2. Having worked in numerous projects and technologies dealing with authorization I am now of the standpoint that the AS can at most do coarse grained authorization. It is far too complex to manage centrally even with authorization tools like XACML. The AS can do some checks and make decisions based on easy to understand details, but to ensure that the client would get a Yes when calling the API given a certain authorization request, would mean not only to have a complex set of policies, but to reverse track their content in order to produce a token that ensures that the API will approve the request. That is in my opinion unmanageable.
      The better approach archetectually is to let the AS act as a PIP (policy information provider) and a coarse grained PDP/PEP (Policy decision/enforcement Point), by issuing a token with enough information in it (claims) that the user has consented to, the API implementation can be made increadibly simple. This falls well in line with the original OAuth spec 6749’s use of the scope claim which only convey a delegation decision. It is up to the API to make the final authorization of the request and decide if the scope is enough together with the other details of the request to authorize the operation.

    I’ve come to consider the Access Tokens to be APIs for the APIs. An organization must define what their tokens contain and how their APIs should react to that information. I.e. what claims are always and sometimes provided in the token no matter format (JWT, Opaque etc). It therefore make a lot of sense to not only define the authorization details as a claims request, but the resulting claims of it as token claims.

    ‌

  20. Takahiko Kawasaki

    My view on the scope, claims and authorization_details is as follows.

    No. Parameter Description Target Standardized?
    1 scope lists permissions. Access Token Yes
    2 scope OIDC Core Section 5.4 defines special scopes to request claims. ID Token UserInfo Response Yes
    3 scope Some implementations support parameterized scopes / dynamic scopes. Access Token No
    4 claims requests claims in a fine-graied way. ID Token UserInfo Response Yes
    5 claims may be able to describe permissions and/or detailed information about an access token in a fine-grained way. Access Token No
    6 authorization_details describe permissions and/or detailed information about an access token in a fine-grained way. Access Token Yes

    ‌

    “if the scope parameter is not expressive enough” in “FAPI 2.0 Baseline Section 2.2.1 Clause 7” is the 3rd case in the table above. “Parameterized Scope” / “Dynamic Scope” is used in some regions and prevailing although the feature is not standardized. Existing implementations and deployments can use the feature until it supports RAR.

    My understanding is that what Travis is proposing is the 5th case in the table above. Because the format of the claims request parameter is JSON, it is capable of describing permissions and/or detailed information about an access token in a fine-grained way.

    It is technically possible, however, the problem of the 5th case is that using the claims request parameter to control information about access tokens is neither prevailing nor standardized.

    The more people in the community put priority on interoperability, the less people support the idea of using the claims request parameter to describe details about an access token.

    I personally feel sympathy for Travis, but if asked, I would say that the community don’t have to dare to open a way to non-interoperability at this timing. I’m sorry I’ve not read draft-spencer-oauth-claims. If the draft gets more support from the community, the situation may change. However, considering that the discussion on RAR has consumed so long time, it is a hard way to go.

    ‌

  21. Ralph Bragg

    Thanks for the table - couldn’t agree more with both its content and the conclusions. I feel partly to blame for the leveraging of an identity claim to convey Authorization details. It was all the OBIE had available at the time even though intended target was wrong.

    ‌

  25. Lukasz Jaromin

    I wasn’t in the previous WG meeting but I’m surprised that this issue is still open and actively debated. These are two different mechanisms invented for different purposes. The fact that it is possible to use the first (claims) in some non-ideal way to solve the problem for which the latter was invented for cannot determine its use.

    @Takahiko Kawasaki great comment

  30. Log in to comment
Assignee
–
Type
bug
Priority
major
Status
resolved
Component
FAPI2: Advanced Authorization
Milestone
2nd Implementers Draft
Votes
0
Watchers
4
Jira: the preferred issue tracker for Bitbucket. Join the team!