What is the value of the thing that comes back from the helper

[michielbdejong]

The thing that comes back from the helper may be just a description of something, or it may actually already be "approved" by the resource owner in some sense.

The "description" case is closest to the scope parameter in an OAuth authorization response. It just describes which client actions the grant covers, and by omission, which client actions it doesn't. The language of this is left out of scope - it can define resources or access modes or any other axis of differentiation.

The "approval" case is what we discussed in our meeting on 22-03-2024, and it gives a bigger task to the helper.

In any case you could also switch the scope-selection step and the audience-check step in the auth server GUI.

[michielbdejong]

Arguments for the "approval" option:

1. It allows the helper to do its own end-user authentication
2. It allows the helper to put some RS-specific info into this approval, for inclusion into the access token, which the RS will understand.

Who holds the revoke list?

In a sense the main AS becomes the third party and it attenuates/delegates to the fourth party: the client

[michielbdejong]

Maybe the main AS holds the grants list but the helper holds some sort of "shares" list, i.e. the scopes it dynamically labels

[michielbdejong]

Discussed with @HarryKodden just now what a good name for 'the thing the helper returns' would be. Options:

• "share" (my current favorite)
  • Pro: the term 'share' or 'file share' is already used in NFS, Azure and Open Cloud Mesh as meaning a file or folder that is being shared, with a certain access mode (read-only or read-write), to a certain audience (list or groups of recipients), and it can also be revoked.
  • Con: it mainly relates to files and not to other types of API resources OAuth could be used to protect, such as payments, flight bookings, etc.
• "resource"
  • Pro: already used in OAuth to mean anything the resource server wants to protect.
  • Con: not related to sharing or giving access; not something you can revoke
• "ticket"
  • Pro: very generic, could mean almost anything.
  • Con: very generic, could mean almost anything ;)
• "scope" (the term I tried using so far)
  • Pro: already used in OAuth, it's literally the scope you select in the scope picker.
  • Con: it mainly has meaning in the context of a token, too close to that

[michielbdejong]

We chose 'scope' for now.
The value of the thing the resource helper returns is purely informational, that's why it has type: "description" in the RH API response, and type: "grant" in the AS API response.

[michielbdejong]

We had another discussion about this today and decided on "approval", not "description".

The reason is that authentication of the resource owner should be an additional task of the resource helper. There is no way to pass that authentication back and forth between AS and RH.

[michielbdejong]

In any case you could also switch the scope-selection step and the audience-check step in the auth server GUI.

-> #39

[michielbdejong]

It's worth noting that the "approval" does have value, but it is a half-product. Only the AS can put it into an access token.

See also #40