Define version of identity attribute profile

[NicolasLiampotis]

We need a mechanism to denote the version of the attribute profile supported by the AARC-compliant proxies. At the same time, the relying parties should be able to signal the version of the profile they support.

E.g. this could be implemented with claims and scopes in OIDC or entity categories in SAML

[NicolasLiampotis]

WIP: In OpenID Connect we can handle core and extended attribute profiles as follows:

1. Define Claims

Create specific claims to differentiate between core and extended profiles:

• aarc_profile_core: Version of the AARC Core Profile
• aarc_profile_ext: Version of the AARC Extended Profile

2. Update the Discovery Document

Include the supported claims in the OpenID Connect Discovery document to inform relying parties about available profiles:

{
  "issuer": "https://example.com",
  "authorization_endpoint": "https://example.com/authorize",
  "token_endpoint": "https://example.com/token",
  "userinfo_endpoint": "https://example.com/userinfo",
  "response_types_supported": ["code", "id_token", "token id_token"],
  [...],
  "claims_supported": ["openid", "profile", "aarc_profile_core", "aarc_profile_extended"],
}

3. Include Profile Information in Claims

The OP should include the profile version and relevant attributes in the ID Token or UserInfo response:

For Core Profile:

{
  "sub": "1234567890",
  "name": "John Doe",
  "email": "[email protected]",
  "aarc_profile_core": "1.0"
}

For Extended Profile:

{
  "sub": "1234567890",
  "name": "John Doe",
  "email": "[email protected]"
  "aarc_profile_core": "1.0",
  "aarc_profile_extended": "1.0"
}

[c00kiemon5ter]

Notice that the claims request approach works for OpenID Connect
but, for OAuth2 clients this will not work.

[msalle]

For completeness, WLCG uses parametric scopes, see

• #requesting-token-versions
• #common-claims
• #claim-and-token-validation

[msalle]

And ideally, we should get a short name (ver ?) registered via the OpenID-RandE working group.

[msalle]

Notice that the claims request approach works for OpenID Connect but, for OAuth2 clients this will not work.

... but also for OIDC it's optional, see https://openid.net/specs/openid-connect-core-1_0.html#ClaimsParameter "Support for the claims parameter is OPTIONAL."
That was originally a motivation for e.g. SciTokens and WLCG to go for "parametric scopes" as a hack/workaround.

[NicolasLiampotis]

Update: Versioning Approach and New AARC Profile Version Attribute Specification

Short Description:

This update introduces a refined versioning approach for the AARC Attribute Profile, as detailed in the newly added Section 2 of the working document. The approach defines a URL with a major.minor versioning scheme, such as

New Specification:

• AARC Profile Version Attribute: The aarc_ver claim is introduced to specify the version of the AARC Attribute Profile. This claim uses the aarc prefix to avoid naming collisions and shortens the version indicator to ver, aligning with OAuth claim naming conventions.

Discussion:

1. Availability: Always available when requested. Proxy implementations SHOULD release the aarc_ver claim when returning any of the attributes included in the AARC Profile even if the aarc scope is not requested.
2. Protocol Support: Support for the aarc_ver claim is limited to OpenID Connect (OIDC). Version can also be encoded in SCIM by defining a proper schema extension.

** Open Issues **

• Agree on the namespace:
  • https://aarc-community.org/attribute/profile/version/X.Y
  • https://aarc-community.org/profile/attribute/version/X.Y
  • https://aarc-community.org/profiles/attribute/version/X.Y
  • Other?

[NicolasLiampotis]

Proposed namespaces:

• https://aarc-community.org/attributes/profile/version/X.Y
• https://aarc-community.org/profiles/attribute/version/X.Y
• https://aarc-community.org/attribute/profile/version/X.Y
• https://aarc-community.org/profile/attribute/version/X.Y

[msalle]

If we put more than attributes in the profile, having profile first would be preferred. If it is only attributes, I would definitely go for attribute first.

[c00kiemon5ter]

The thing we are defining is a profile, thus "profile" should be the top level resource.

I think "attributes" should not be there at all.

What we probably need is a name for this profile. This means that later we can introduce more profiles with different names for different purposes.

https://aarc-community.org/profile/<name>/version/X.Y

[msalle]

I kind of agree, but could you give an example of what you would put as name? If this would be abstract such as espresso in refeds, it could become very vague:

1. https://aarc-community.org/profile/cauliflower/version/1.1
2. https://aarc-community.org/profile/hedgehog/version/1.2

where 1. would refer to e.g attributes and 2. to for example assurance?

[NicolasLiampotis]

Hi @c00kiemon5ter,

Based on your suggestion for https://aarc-community.org/profile/<name>/version/X.Y, would the following examples fit your proposal?

• https://aarc-community.org/profile/identity/version/1.0
• https://aarc-community.org/profile/id/version/1.0
• https://aarc-community.org/profile/attributes/version/1.0
• https://aarc-community.org/profile/attrs/version/1.0
• https://aarc-community.org/profile/id-attrs/version/1.0

@msalle do you think using names like "identity", "id", or "attributes" would address the ambiguity issue you pointed out?

Thanks!

[c00kiemon5ter]

I am re-reading the thread to remember the discussion

We need a mechanism to denote the version of the attribute profile supported by the AARC-compliant proxies

• I think what we need is a way to advertise the supported profile(s).
• I think we should not think of the profile we are working on as an attribute profile. There is no reason to limit it and worse trying to make that part of the description of the profile. Let's leave this open.
• The profile would be denoted by a URI-string. That can include the version. We do not need a separate piece of information for the version.

---

what you would put as name

I think we need to think the purpose of the profile.
We should not think what is being profiled (technicality), but why (business value).

---

https://aarc-community.org/profile/proxy-interoperability/v1.3

The "aarc-community" provides a "profile" for "aarc-proxies".
The profile has gone through multiple stages and is now on version "v1.3".
It is implied that other minor versions are supported.
A proxy can support more profiles, ie

https://aarc-community.org/profile/aarc-proxies/v1.3
https://aarc-community.org/profile/aarc-proxies/v2.0
https://aarc-community.org/profile/special-case/v0.2

[msalle]

It definitely looks reasonable although I'm not sure this would always work/be possible. I'm thinking about:

• for example the Assam assurance profile (which currently uses https://aarc-project.eu/policy/authn-assurance/assam ). If we would name profiles after things, how would that work, or shouldn't we?
• not all profiles would have a necessarily clearly defined/single audience or purpose?

[NicolasLiampotis]

If we adopt an AARC proxy profile versioning approach that is not specific to attributes (e.g., the proxy interoperability profile https://aarc-community.org/profile/aarc-proxies/vX.Y suggested by @c00kiemon5ter), we need to define when a version bump occurs. Using the example of an updated AARC-G056 attribute profile specification (e.g. introducing a new attribute):

• If the new attribute is core/mandatory for proxies to maintain interoperability, a version bump for the proxy interoperability profile might be necessary.
• If the update adds optional attributes or features that proxies can support without breaking existing functionality, the version could remain unchanged, with documentation highlighting the optional extensions.

Open Questions

• Should the proxy interoperability profile version bump for any new guidelines that affect proxies? A possible approach:
  • Major Version Bump: For breaking changes or mandatory functionalities that proxies must implement to remain compliant.
  • Minor Version Bump: For non-breaking changes, such as optional features or clarifications.
• If a proxy implements one updated guideline (e.g., a revision of AARC-G056) but not another, can it bump its version?
• Do we need a mechanism for proxies to explicitly advertise support for specific guidelines to address such cases?

[NicolasLiampotis]

Summary from the 2024-11-25 meeting and updated during the 2024.12.16 meeting:

Proposed Changes

Version Signalling

• Each guidelines document can increment the proxy interoperability version.
• Proxies SHOULD advertise the version(s) of the interoperability profile they implement.

Relying Party Requirements

• Relying parties acting as end-services MAY signal the required interoperability profile version
• Relying parties acting as AARC-compliant AAI services MUST signal the required interoperability profile version

Support for Multiple Profiles

• Proxies SHOULD support multiple interoperability profiles during transition periods to ensure seamless integration.
• Proxies SHOULD be able to provide a profile for relying parties that don't request a specific version.

Scope Advertisement

• Proxies MUST advertise supported interoperability profiles through the scopes_supported claim in their OP Config metadata, as per OIDC Discovery and RFC8110.
  • Example: Include https://aarc-community.org/profile/aarc-proxies/vX.Y in scopes_supported.

Backward Compatibility

• Breaking changes or backward-incompatible updates SHOULD be avoided to minimise disruption during transitions.