---
# System prepended metadata

title: Resource Helper

---

# Resource Helper

Unconference Session at OSW 2024 Rome


Diving into detail about the Resource Helper presentation from this morning.

## Topics
* Client->AS:
  * Pre-Dance vs Sub-Dance
    -> Sub-Dance: no client changed required, AS checks trust, is the user allowed to use the RS (= policy on the AS)? This requires authentication of the user os the AS.
  * Resource server selection
    -> Use the "resource" or "audience" parameter to specify a specific resource?
    
    -> Put selecting a resource server by protocol (and getting the the client configuration) in a separate protocol
    
* AS->RH:
  * How can the AS give session context to the RH? RAR/PAR maybe?


* RH-> AS:
  * Should we use UMA Resource Registration or GNAP-RS Resource Registration?
    -> GNAP-RS, newer, desing without being restrained by OAuth from 2015.
    
  * Is Resource Registration just informational?
    -> No, the RO at the RH has authorized access to the resource. The authorization MAY still be refused at the AS.

  * But is the redirect back RH to AS already an authorisation?
    -> Yes, but not yet sufficient for getting a token. See above.
    
* AS->Client:
  * Can we use *Enriched Authorization Details in Token Response* from [RAR spec §7.1](https://datatracker.ietf.org/doc/html/rfc9396#name-enriched-authorization-deta)?
    -> Should use a configuration API. Should we use a .well-known endpoint for communicating this API endpoint -> no. This is static, just configure it in the client along with the other required info.

  * a POST response mode instead of the Scope Info endpoint?
    -> not discussed

 * Next steps?
-> Two specs. Let us know if you are willing to help or want to keep informed by adding your name below. e.g. review:

- pieter.vandermeulen@surf.nl
- michiel@pondersource.com
- 
- 


 * Alignment with other standards
   -> see above ;)
   
 * Naming: What are we going to call this?
   -> Naming is hard

 * ...

## Links from this morning's presentation
Abstract: https://github.com/SURFnet/surf-token-based-access/blob/dev/phase-2/osw-abstract.md
Slides: https://github.com/SURFnet/surf-token-based-access/blob/dev/phase-2/osw2024-slides.pdf
Demo: https://github.com/SURFnet/surf-token-based-access/blob/dev/phase-2/poc-3/README.md


Notes Michiel:
- gnap-rs instead of uma for RR
- split resource helper from scope info
- resource helper is interesting
- scope info might get pushback
  - resource discovery
  - resource server discovery / selection -> resource parameter, not aud?
  - protocol discovery -> no! protocols field in scope info is confusing
- reasons for subdance:
  - policies about which RS is trusted for which RO and which Client under which conditions may changing daily
  - don't ask clients to keep this list updated, leave that to the AS
  - compared to GNAP predance: backwards-compatible with pre-GNAP clients
  - AS in role of trust broker scales down the number of trust links from `#C * #RS` to `#C + #RS`
- protect AS-RH interaction against phishing!
- How can the AS give session context to the RH? RAR/PAR maybe? OIDC-something? UMA claims gathering?

- for AS->RH session context, maybe the RH can query an AS API?
- is the linking of RH identity to AS identity an opening for phishing?