Consider additional context on AS / UMA

Open
#152 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
35/100
Issue type
Documentation
Clarity
Mostly clear
Activity status
Stale
Domain
authentication, documentation, security

Research direction

Start with the Solid-OIDC sections on Authorization Server Discovery and Obtaining an Access Token, then review the Primer and the linked UMA flow. Done means adding non-normative implementation context and a separate UMA-based example flow that explains its benefits without changing normative requirements.

Written by the indexing model from the issue text.

Description

doc: solid-oidc doc: solid-oidc-primer editorial

In the recently submitted iteration of the Solid-OIDC specfication there are references made to an Authorization Server that SHOULD implement a UMA 2.0 Grant for OAuth 2.0 Authorization (UMA).

Specifically:

In Authorization Server Discovery:

Authorization Servers SHOULD implement User-Managed Access (UMA) 2.0 Grant for OAuth 2.0 Authorization [UMA].

In Obtaining an Access Token:

For Authorization Servers that conform to [UMA], the http://openid.net/specs/openid-connect-core-1_0.html#IDToken profile MUST be supported. This profile MUST be advertised in the uma_profiles_supported metadata of the Authorization Server discovery document User-Managed Access (UMA) 2.0 Grant for OAuth 2.0 Authorization § rfc.section.2.

When using the http://openid.net/specs/openid-connect-core-1_0.html#IDToken profile with an UMA-based Authorization Server, the Authorization Server MUST be capable of exchanging a valid Solid-OIDC ID Token § 8.1 DPoP-bound OIDC ID Token for an OAuth 2.0 Access Token.

Note: Clients can push additional claims by requesting an upgraded RPT User-Managed Access (UMA) 2.0 Grant for OAuth 2.0 Authorization § rfc.section.3.3.1

Authorization Server MUST pefrom § 9.3 DPoP Validation and § 8.1.1 ID Token Validation

I don't believe any more normative detail needs to be added to the Solid-OIDC specification on this subject - but I do think that non-normative supplementary context should be provided to support adoption by developers of Solid-OIDC implementations and the users of those implementations, possibly in a separate document.

For example, Solid Community Server bundles in an existing OpenID Provider that conforms to Solid-OIDC. It would seem that to be fully conformant they would also need to bundle in an AS that implements UMA. Client-side authentication libraries would similarly need some adjustment. I'm sure an overview detailing these considerations would be useful and welcome.

Consequently, it would helpful to showcase the real benefits of a UMA flow in the primer, separately from a "classic" Solid-OIDC flow. I know that the Primer accurately reflects the changes in the specification, but it does little to demonstrate the benefit of them. A second "robust" flow that showcases those benefits could help motivate implementations to fully support this functionality.

Dominant language
Bikeshed
Stars
26
Forks
14
No merged PRs in 30d

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from solid/solid-oidc

All issues in solid/solid-oidc

Similar issues

More Security issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.