Consider support for RFC7643

[jjg-123]

We do support RFC 9068 -- the basic access token specification using a JWT. In that specification, it recommends using RFC 7643 for System for Cross-domain Identity Management (SCIM) to describe groups and roles. We don't do that but easily could. This ticket is to remind me to set time aside to consider this and discuss it. https://www.rfc-editor.org/rfc/rfc7643

A large objection to using SCIM in the access token is that there is a considerable amount of private data in the entire specification we should not support, such as phone numbers and email addresses. The philosophy at this point is those go into the ID token (aka user metadata) and things related precisely to accessing a resource go into the access token. It just seems like RFC 9068 wants to put this in the wrong place. So while it may be fine to allow for using this as an alternate ID token protocol, only at best a subset applies to RFC 9068 and access tokens.

[msalle]

Hi Jeff,
For which profiles are you thinking about this? Or more in general ? WLCG is currently using wlcg.groups but there has been talk to change to RFC9068. There has been some discussion about the strict rules of SCIM about how to format the groups.
And concerning the whole SCIM schema, I would probably at most use (at least at first) the set used by RFC9068, so groups, roles and entitlements. But even then these might not be an easy match for our use of similar claims I think?

[jjg-123]

On 1/30/24 03:02, msalle wrote: Hi Jeff, For which profiles are you thinking about this? Or more in general ? WLCG is currently using wlcg.groups but there has been talk to change to RFC9068. There has been some discussion about the strict rules of SCIM about how to format the groups.

The RFC 9068 spec says to use RFC 7643 for groups, roles etc., but does not seem to promote much else. It does seem to make good sense to use parts of the specification for that. Right now groups are returned by OA4MP in the isMemberOf claim unless someone has a policy that requires something else, so we really don't have a good way to do it generally. OA4MP does not have concept of a user but does of course allow for multiple identities and logins (as per CILogon). At this point there is no need to support RFC 7644 (the REST API that permits exchanging SCIM objects), but simply the object themselves. One possibility I was thinking of was as an alternate to the ID token (which is OIDC specific) so a SCIM object could be requested with a scope and that would be supported for standard OAuth client too. It could also be returned as a JWT and signed. This is just a possibility at this point.

And concerning the whole SCIM schema, I would probably at most use (at least at first) the set used by RFC9068, so groups, roles and entitlements. But even then these might not be an easy match for our use of similar claims I think?

Yes. OA4MP should support as many standards as make sense, but more than the basic parts of RFC 7643 are a good question. I made the issue because I wanted to discuss it with people and get feedback, but I really don't have a strong use case for it now. Jeff