meeting 28 March

[michielbdejong]

• [x] header on each page
• [x] SRAM can mean many things
• [x] scope back from secondary: webdav-folder

[michielbdejong]

funny insight: we're not actually using the scope parameter to identify scopes at all! The code is what identifies the grant, and thus the scope.

[michielbdejong]

• [x] type 'ticket' -> type 'description'. has no value! gives no access to the resource!

[michielbdejong]

the resource server shares a language with secondary server the resource server either:

• parses the access token to get all the info
• calls introspection endpoint on primary auth server https://datatracker.ietf.org/doc/html/rfc7662 (add scopeInfo in the /introspect response?)

[michielbdejong]

distinguish two information flows:

• secondary -> client
• secondary -> resource server (either via introspect or via token parsing)

[michielbdejong]

two options for secondary -> resource server, if via introspect:

• primary stores opaque info from secondary
• primary delegates the introspect to the secondary

[michielbdejong]

• [x] rename 'primary' to 'the'

[michielbdejong]

• [x] rename 'secondary' back to 'resource helper'

[michielbdejong]

sometimes the client will not need config info, but the RS still needs the RH

[michielbdejong]

• [x] make diagrams for presentation
• [x] document all design choices in the repo / spec text.

[michielbdejong]

where do we come from, which problem do we want to solve, why do we do it this way, what did we put into it conceptually