[JIRA] (JOIDC-11) Support for client_credentials grant

[Scott Cantor (Jira)]

Scott Cantor ( https://shibboleth.atlassian.net/secure/ViewProfile.jspa?accountId=557058%3A5b78efc9-1379-42cc-a3f6-56c6ea3a0007 ) *commented* on JOIDC-11 ( https://shibboleth.atlassian.net/browse/JOIDC-11?atlOrigin=eyJpIjoiYWU4OGU3Njk5MzkwNDA3N2JiZGRiNzQxZjFjZmNjZWUiLCJwIjoiaiJ9 )

Re: Support for client_credentials grant ( https://shibboleth.atlassian.net/browse/JOIDC-11?atlOrigin=eyJpIjoiYWU4OGU3Njk5MzkwNDA3N2JiZGRiNzQxZjFjZmNjZWUiLCJwIjoiaiJ9 )

As I’m working through encryption support, a lot of potentially complex issues emerge about the different perspectives on who the “relying party” is in this use case, and I think it’s both the client and the resource server(s) at the same time.

Our model doesn’t accomodate that particularly well, but I think I’ve convinced myself that it may be more like “a little bit the client early on” but “mostly the resource server”, made more complex by the only partial support in the overall spec for multiple audiences (e.g. no multi-cast encryption support). Even values like the issuer string can’t actually matter to the client, only the audience.

I’m starting to come around to the idea that we should just disallow multiple “true” audiences for this kind of use case under the guise that the audience is abstracted anyway, so 100 resource servers could all be one, while still allowing there to be multiple values in the token, allowing one audience to be further restricted as to which specific resource server would be allowed. We have some latitude here simply because the specs for all this are not interoperable anyway.

The advantage is that it could let us “flip” the relying party identity mid-flow to the “primary” audience, and assuming it’s permitted to proceed with or without client metadata for the resource server, the rest of the flow would operate based on that. Attributes would be resolved about the client but the requester would be the resource server, which is in fact what’s happening here anyway. That fits our filtering notion better anyway.

The interesting side effect is that it allows for either both the client/resorce identities to require metadata verification or neither to require it. That seems like a more valuable feature than requiring client metadata but not resource server metadata and not allowing the converse, but this needs more thought. It had been my working assumption that clients would have to be registered, but I’m not sure that is always desirable for this use case.

( https://shibboleth.atlassian.net/browse/JOIDC-11#add-comment?atlOrigin=eyJpIjoiYWU4OGU3Njk5MzkwNDA3N2JiZGRiNzQxZjFjZmNjZWUiLCJwIjoiaiJ9 ) Add Comment ( https://shibboleth.atlassian.net/browse/JOIDC-11#add-comment?atlOrigin=eyJpIjoiYWU4OGU3Njk5MzkwNDA3N2JiZGRiNzQxZjFjZmNjZWUiLCJwIjoiaiJ9 )

Get Jira notifications on your phone! Download the Jira Cloud app for Android ( https://play.google.com/store/apps/details?id=com.atlassian.android.jira.core&referrer=utm_source%3DNotificationLink%26utm_medium%3DEmail ) or iOS ( https://itunes.apple.com/app/apple-store/id1006972087?pt=696495&ct=EmailNotificationLink&mt=8 ) This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100190- sha1:4ce3a7c )
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/commits/attachments/20220203/cc0507ec/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jira-generated-image-avatar-57df0081-42d7-4845-809e-361e6f007134
Type: image/png
Size: 341 bytes
Desc: not available
URL: <http://shibboleth.net/pipermail/commits/attachments/20220203/cc0507ec/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jira-generated-image-static-comment-icon-8f3661ca-6d21-466d-80a0-315e6f215242
Type: image/png
Size: 1084 bytes
Desc: not available
URL: <http://shibboleth.net/pipermail/commits/attachments/20220203/cc0507ec/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jira-generated-image-static-footer-desktop-logo-74777710-1f63-465f-ba6e-628fa3589429
Type: image/png
Size: 10805 bytes
Desc: not available
URL: <http://shibboleth.net/pipermail/commits/attachments/20220203/cc0507ec/attachment-0005.png>