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

scopes metadata parameter needs to be defined

Issue #1456 resolved
Torsten Lodderstedt created an issue

The example in section 3.1 of the federation spec uses a metadata element “scopes” underneath “openid_relying_party” but this parameter is undefined yet.

OpenID Connect Dynamic Client Registration does not define any scope related element. RFC 7591 defines an element “scope” as a "String containing a space-separated list of scope values”.

I think there are two options: “scopes” is retained and defined or the spec is changed to use the “scope” definition from RFC 7591 (and RFC 6749).

Comments (18)

  1. Giuseppe De Marco

    In the example of the entity statements, in the metadata policy values.
    @roland Is there any consideration or impediment to converge on the use of the claim scope and abandon Scopes? 

        "openid_relying_party": {
      "organization_name": {"value": "NTNU"},
      "grant_types_supported": {
        "subset_of": ["authorization_code", "implicit"]},
      "scopes": {
        "subset_of": ["openid", "profile", "email", "phone"]}
    }

    ‌

  2. Kristina Yasuda
    • changed status to open

    2022-Mar-10 Connect call. We discussed the benefit of scopes array. It was pointed out that scope and scopes might be confusing and better name for scopes should be considered.

  4. Torsten Lodderstedt reporter

    I think we should revert the name change. „scope“ as array completes the confusion as it deviates from the OAuth definition. Or we use a completely different term as suggested in the last call.

  6. Michael Jones

    The specification’s use of scope now appears to be aligned with OAuth 2.0, and scopes is gone. I propose that we close this issue on that basis.

  7. Giuseppe De Marco

    I didn’t understand if in the metadata policy claim, in the entity statement, the correct claim name is scope or scopes
    I’m completely neutral with this, I just need the final decision to update my implementations

  8. Torsten Lodderstedt reporter

    I cannot find a definition of how this policy

    ‌ "scope": {

    ‌ "subset_of": ["openid", "profile", "email", "phone"]}

    can be applied to a client policy of this form

    "scope": "read write"

    Additionally, the spec refers to the OpenID Connect Client Registration spec only (which does not define “scope”). A reference to RFC 7591 needs to be added to enable RP policies to use “scope”.

  9. Giuseppe De Marco

    the intersection of read write and openid profile email phone returns a void array
    this means that the default value would be applied if present in the metadata_policy, if a default value is absent the OP would reject the request because it’s not openid compliant

  10. Torsten Lodderstedt reporter

    You seem to assume the string scope represents a set of scope values (so ordering e.g. does not matter)? That needs then to be stated in the spec since it is not defined someplace else.

  11. Giuseppe De Marco

    I read in 5.1. Metadata Policy
    Each policy entry applies to one metadata parameter, such as id_token_signing_alg.
    I assume that all the claims defined in OIDC Dynamic client registration and Provider discovery can be modified by a policy, the ordering of the values doesn’t matter.

    ‌

  12. Michael Jones

    As discussed on the 21-Apr-22 working group call, https://datatracker.ietf.org/doc/html/rfc6749#section-3.3 says this about scope values:

    The strings are defined by the
   authorization server.  If the value contains multiple space-delimited
   strings, their order does not matter, and each string adds an
   additional access range to the requested scope.

    It’s a separate but related question whether we need to repeat this in the Federation spec.

    ‌

  13. Giuseppe De Marco

    In “OpenID Connect Discovery 1.0“ in “OpenID Provider Metadata“ we have the claim scopes_supported.

    In “OpenID Connect Dynamic Client Registration“ we don’t have any claims called scope or scopes.

    As you mention RFC6749 has this claim in the OAuth2 Client metadata and as I can see the current OIDC Fed specs also mentioned this here and in the non normative example of the Entity Statements and 5.1.5. Policy Combination Example.

    If there were no further comments I would consider this issue resolved and ready to close :-)

    ‌

  14. Michael Jones

    As discussed on the 21-Apr-22 working group call, https://datatracker.ietf.org/doc/html/rfc6749#section-3.3 says this about scope values:

    The strings are defined by the authorization server. If the value contains multiple space-delimited strings, their order does not matter, and each string adds an additional access range to the requested scope.

    I will add a reminder that this is the case to the specification. Then we should be able to close this issue.

  15. Torsten Lodderstedt reporter

    @guiseppe: I’m not aware of a definition of client metadata in RFC 6749. So there is still no definition of “scope” as client metadata parameter at all. I suggest to add it to the federation spec.

  16. Giuseppe De Marco

    thank you @torsten, scope it’s for AS and not for client, my bad, so the meaning of my comment is related to the OP metadata.
    I don’t see any need to define scope for the RP metadata in oidc federation 1.0. If I miss something or you like the scope in the RP metadata, please share your good points here 🙂

  19. Log in to comment
Assignee
Type
bug
Priority
major
Status
resolved
Component
Federation
Milestone
–
Version
–
Votes
0
Watchers
1
Jira: the preferred issue tracker for Bitbucket. Join the team!