Consider additional context on AS / UMA

Aperta
#152 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
35/100
Tipo di issue
Documentazione
Chiarezza
Abbastanza chiara
Stato di attività
Ferma
Ambito
authentication, documentation, security

Direzione di ricerca

Inizia con le sezioni di Solid-OIDC su Authorization Server Discovery e Obtaining an Access Token, quindi esamina il Primer e il UMA flow collegato. Il lavoro è completato quando vengono aggiunti un contesto di implementazione non normativo e un flusso di esempio separato basato su UMA che ne spieghi i vantaggi senza modificare i requisiti normativi.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.

Lingua principale
Bikeshed
Stelle
26
Fork
14
Nessuna PR unita negli ultimi 30g

Guida per i contributori

Nessuna guida per i contributori indicizzata per questo repository

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di solid/solid-oidc

Tutte le issue di solid/solid-oidc

Issue simili

Altre issue su Security

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.