search

aarc-community / architecture-guidelines

3 stars 0 forks source link

Define version of identity attribute profile #16

Open NicolasLiampotis opened 7 months ago

NicolasLiampotis commented 7 months ago

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 commented 3 months ago

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:

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": "johndoe@example.com",
  "aarc_profile_core": "1.0"
}

For Extended Profile:

{
  "sub": "1234567890",
  "name": "John Doe",
  "email": "johndoe@example.com"
  "aarc_profile_core": "1.0",
  "aarc_profile_extended": "1.0"
}
c00kiemon5ter commented 3 months ago

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

msalle commented 3 months ago

For completeness, WLCG uses parametric scopes, see

msalle commented 3 months ago

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

msalle commented 3 months ago

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 commented 3 months ago

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:

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

NicolasLiampotis commented 2 months ago

Proposed namespaces:

msalle commented 2 months ago

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 commented 2 months ago

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 commented 2 months ago

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 commented 2 months ago

Hi @c00kiemon5ter,

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

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

Thanks!

c00kiemon5ter commented 2 months ago

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

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 commented 2 months ago

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

NicolasLiampotis commented 1 week ago

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):

Open Questions