1. OpenID Foundation Avatar OpenID Foundation
  2. WGs
  3. ekyc-ida
  4. Issues

Client Registration Metadata

Issue #1371 new
Ralph Bragg created an issue

There exists a need to be able to control what claims are requestable by a relying party by a federation controller. Whilst OPs have had defined metadata for advertising the claims that they support, the current specification is silent on controlling or restricting the metadata that a relying party can be registered with to just OIDC registration.

Can the metadata be agreed and registered to include the ability to restrict the mechanisms available to RPs please and if possible can the WG provide early direction for the RP registration metadata for claims_in_verified_claims_required equivalent to the OPs claims_in_verified_claims_supported

This metadata is necessary for a federation implementing this specification to have as soon as possible and to avoid rework by RPs and OPs it would be great if we could agree this.

Comments (20)

  2. Takahiko Kawasaki

    I were asked, I would suggest _requestable as the suffix for the purpose. For example, like claims_requestable and claims_in_verified_claims_requestable.

  3. Dima Postnikov

    Discussed in eKYC WG today. Decided to (1) agree on names, (2) create a separate document describing this metadata, extension of https://openid.net/specs/openid-connect-registration-1_0.html and (3) register the names via IANA?

    ‌

    One (1), should OIDC and EKYC RP metadata mimic OP metadata?

    E.g.: claims_supported and claims_in_verified_claims_supported

    claims_supported

    RECOMMENDED. JSON array containing a list of the Claim Names of the Claims that the Relying Party MAY be able to request.

    claims_in_verified_claims_supported

    RECOMMENDED. JSON array containing a list of the Claim Names of the Verified Claims that the Relying Party MAY be able to request.

    ‌

    Alternative 1

    claims_required and claims_in_verified_claims_requiredbut it feels wrong because RP might not actually require it or require it for every use case.

    Alternative 2

    claims and claims_in_verified_claims (or even verified_claims)

    A little more aligned with OAuth 2 Dynamic registration but less aligned with OP metadata as described above https://datatracker.ietf.org/doc/html/draft-ietf-oauth-dyn-reg-20

       scope
      Space separated list of scope values (as described in Section 3.3
      of OAuth 2.0 [RFC6749]) that the client can use when requesting
      access tokens.  The semantics of values in this list is service
      specific.  If omitted, an authorization server MAY register a
      client with a default set of scopes

    ‌

    ‌

    @Ralph Bragg WDYT?

  4. Takahiko Kawasaki

    In my opinion, scope in the dynamic client registration should have been defined like scopes_requestable whose value is an array (not a space-delimited string). During a certain call of the GAIN PoC Community Group, I pointed out that the OIDC Federation specification had to treat the scope with a special care, and as a result, Issue 1837 [Federation] metadata policy - relying party, claim "scope" was created. In my opinion, we don’t necessarily have to follow old traditions when we find a better and more intuitive way.

  6. Ralph Bragg reporter

    I too have long thought that _requestable or some other word is better grammatically and conveys clearer meaning but that ship has long sailed.

    If the WG wants to try and bring that into the spec then i’m all for it, likewise i’m OK with claims_supported and claims_in_verified_claims_supported. My primary concern is avoiding rework and achieving interop.

  7. Dima Postnikov

    In all discussions we had, there was no objection to the requirement itself and standardisation of the metadata names.

    The outstanding questions are around naming and the which specification this should go to.

    I will summarise the current options for naming:

    Option 1: Simplest claims and claims_in_verified_claims

    Option 2: claims_supported and claims_in_verified_claims_supported

    Option 3. claims_requestable and claims_in_verified_claims_requestable

    • Ecosystem using these will determine what “requestable“ actually means (allowed to, able to support, or etc.).
    • Might be a bit more specific but still might mean different things to different implementers.

    Keen to hear some opinions re naming: Mark@Giuseppe De Marco @Vladimir Dzhuvinov @Ralph Bragg @Nat Sakimura @Takahiko Kawasaki

    All options are slightly misaligned with OAuth’s scope (plural vs singular). Plural makes more sense, so I am not suggesting claim and claim_in_verified_claim as this can cause further confusion.

    There is also issue with scope definition that @Takahiko Kawasaki pointed out above Issue 1837 [Federation] metadata policy - relying party, claim "scope".

    ‌

    ‌

  8. Mark Haine

    I like “allowed” and “requestable” better because they are morte specific but I think we should also be as specific as possible in the definition of these metadata items in order that semantic differences are minimised and interoperability goals are more likely to be achieved.

  9. Dima Postnikov

    I agree with the intent of being more specific, in general.

    But a lot of times the actual specifics is up to ecosystem (client governed, OP governed or some other governance authority governed).

    Sometimes it indicates that client is capable of supporting a certain claim (). Some other times it means they are allowed by some governance authority to request it because they have been accredited to a certain level.

    This makes it hard to pick a right verb. Hence my suggestion is to continue without a verb…

    ‌

  10. Vladimir Dzhuvinov

    I welcome this development, thanks Ralph and everybody here for bringing this forward. With OIDC Federation and the ability to define policies and what is allowed (or not) via the trust chain the utilty for such metadata parameters becomes apparent. This reminds me of the code_challenge_method for OAuth clients that I’ve been trying to get registered via the OAuth 2.1 spec because right now we have no standard way to express this.

    Is the claims_requestable intended for general use (regular + verified claims), or only for regular claims? This could work, provided there won’t be situations where a certain claim will be requestable as both regular and verified claim.

    ‌

    ‌

  11. Joseph Heenan

    re: “Ecosystem using these will determine if this means “allowed“, “supported“ or “requestable““ - I’m not sure I understand the nuance of this phrasing, but I think we’d need to have a really reason to define behaviour that differs from that defined for scope in https://www.rfc-editor.org/rfc/rfc7591.html#section-2 - namely:

    scope
      String containing a space-separated list of scope values (as
      described in Section 3.3 of OAuth 2.0 [RFC6749]) that the client
      can use when requesting access tokens.  The semantics of values in
      this list are service specific.  If omitted, an authorization
      server MAY register a client with a default set of scopes.

    ‌

    ‌

  12. Dima Postnikov

    @Joseph Heenan I am not proposing to change the behaviour above.

    I am talking about the governance process that sets these or default scopes (or claims). The nature of this process impacts whether it is “allowable“, “capable“, “paid for“ or “requestable“ is implied. IMO it impacts the accuracy of the name. And if it’s not accurate, it might be confusing.

    That’s why I am suggesting to keep it generic “scope“, “claims“ etc

  13. Dima Postnikov

    Good point @Vladimir Dzhuvinov

    The original intent was to determine if an RP can request date_of_birth for example.

    Independently, if it’s delivered via standard claims or verified claims.

    But I felt that given the special nature of verified_claims, it is easier for OPs if these spelled out separately, e.g. if date_of_birthis allowed in both then RP metadata will be:

    claims = date_of_birth

    verified_claims = date_of_birth

  14. Joseph Heenan

    I am talking about the governance process that sets these or default scopes (or claims). The nature of this process impacts whether it is “allowable“, “capable“, “paid for“ or “requestable“ is implied. IMO it impacts the accuracy of the name. And if it’s not accurate, it might be confusing.

    I understand now. Thank you. I’d probably sway towards option 1.

    It’s probably worth asking the IANA expert that would have to approve the addition to the IANA registry (Justin Richer in this case).

  15. Mark Haine

    Having thought about this and listened to the discussions I have changed my view and think we should go without any descriptive suffix like “allowed“, “supported“ or “requestable“. I do think though that we should be specific about how these new named items of Client metadata may be used.

    Secondly I would say that if interoperability is an outcome we wish to achieve with these new items of client metadata really should be registered with the iana registry linked by Joseph earlier in these comments.

  17. Ralph Bragg reporter

    Hi All - do we have an update on this as an agreement? Option 1 seems preferred. I need confirmation of the client registration metadata because its not clear. claims_in_verified_claims

  18. Dima Postnikov

    @Ralph Bragg we agreed on Option 1. I just need to find a right place and time to document it.

  19. Ralph Bragg reporter

    Given that we’re using scope, i’m going to make the assumption that the error handling for when a client requests something that it is not authorised to have then the same semantics for error handling will apply. e.g invalid_claim will be thrown if a client requests a claim that it is explicitly not authorised for.

  20. Ralph Bragg reporter

    Hi,

    I need further clarification on the behaviour expected by OPs when a client attempts to request a claim or a claim_in_verified_claim that they are not registered for.

    I am working with an implementation that has coded the same behaviour that they have implemented for scopes. If you request a scope that the client is not registered for then the PAR / Authorisation request is rejected with an access_denied message.

    An alternative behaviour could be for the OP to ignore requested claims that the client has requested that they are not registered to have.

    The lack of a consistent behaviour creates interoperability issues so it would good to clarify the expected behaviour here at the WG Level.

    RB

  21. Log in to comment
Assignee
Type
enhancement
Priority
major
Status
new
Component
Core eKYC&IDA
Milestone
–
Votes
1
Watchers
9
Jira: the preferred issue tracker for Bitbucket. Join the team!