Minutes interim-2021-oauth-04: Mon 12:00
minutes-interim-2021-oauth-04-202104051200-00

Meeting Minutes Web Authorization Protocol (oauth) WG
Date and time 2021-04-05 16:00
Title Minutes interim-2021-oauth-04: Mon 12:00
State Active
Other versions markdown
Last updated 2021-04-05

minutes-interim-2021-oauth-04-202104051200-00

OAuth WG Interim Meeting - RAR

Date

5 April, 2021, 12:00pm EDT

Topic - RAR

Presenter: Torsten Lodderstedt
Draft: https://datatracker.ietf.org/doc/draft-ietf-oauth-rar/
Slides: RAR Slides

Notes

Note taker: Brian Campbell

Rifaat: notewell & upcoming meetings

Torsten: begins presenting RAR slides:... "new parameter "authorization_details" to convey fine grained and structured authorization data as JSON objects for when “scope” is not sufficient.
Also used by GNAP and continuous synchronization
Changes since IETF-107. 3 new versions. better readability. Clarifications, dependencies between "resource" and "authorization_details", enrichment, unknown. +implementation considerations.
Implementation Considerations expectations (presentation, modification, merge) and some options (redirect, callbacks, API, fork, etc).
Open Topic: authorization_details token request parameter
Assign privileges to first access token
Downscope privileges of pre-existing grant
Request access tokens with client credentials
"Tricky part" is that Requested and previously granted authorization details need to be compared

Justin takes over presenting w/ "Comparing Authorization Details"
Notes that this kind of comparing happens already with scopes but "possible to do a simple set comparison and mostly get away with it"
Comparing authorization details
Don’t say anything? and Hope for the best!
Compare JSON objects? and deal with Normalization required which Makes assumptions about API design
Leave it out of scope so it's Fully defined by type value
Editors’ proposal: Give some examples for comparison practices, but leave it up to the type definition
A number of examples are shown: simple, subsumption, defaults, added detail, more objects, arbitrary API designs (all are 'correct' and OAuth doesn’t take a stance on the nature of the API)
Phil: why not just return all the scopes (?)
Justin: it's not about the client but how the AS understands and compares and displays
Aaron P: AS may not know overlap of scopes so RS enforces
Torsten: clarifies that there's more to it than communicating to the client
Justin: proposing that the draft Provide guidance
Concepts of a request being “more” or “less” than another - Needed in refresh tokens, user consent, authorization
API designers need to consider this when defining the type they use
AS implementers need to make comparisons - Custom: whatever makes sense for the API / General-purpose: pluggable comparison system? (see implementation considerations)
Spec can show common patterns as example
Phil: making some observations. suggests that this changes the fundamental relationship of the AS. In Oauth traditional the AS usually knows what roles a client may have. The RS only needs to enforce what roles mean. The RS is "stateless" as to what client a or b is.
Justin: wholeheartedly disagree that it changes the model. it depends
Phil: the AS isn't authorizing now, it's consenting. We need to express that.
Justin: that all exists now. So that kind of text should go in 2.1. RAR doesn't change that. It just introduces more complex data comparisons.
Torsten: aggree
Phil: worries that it's not easy for anyone to understand
Rifaat ok but we have more people in queue
George: the scope set math does useally work. this is much more difficult and the AS has to know about the API details
Justin: that's true and what we are trying to describe in the draft and that it is type specific.
Jeff Craig: seems difficult for the client. client will need to know about the API
Justin: yeah. clients are mostly written for specific APIs. RAR is just a means to pass the data.
Aaron: spec assumes the client knows what to ask for
Hannes: Would standardizing a more dynamic "interaction model" be desirable from your experience?
Justin: not seeing the need for standardizing the dynamic
Torsten: might be a topic of future work
Jeff Craig: FWIW, I see this making a lot of sense for transactional interactions like finance, less sure about other cases.
Vittorio: authz is a deep hole. have you considered other policy languages? alpha xacml etc
Justin: we didn't want to get into defining policy
Rifaat: and we are out of time, thanks all

Attendees

  • Rifaat Shekh-Yusef (chair)
  • Hannes Tschofenig (chair)
  • Torsten (Presenter)
  • Justin Richer (Presenter)
  • Dick Hardt
  • Anthony Nadalin
  • Giuseppe De Marco
  • Karsten Meyer zu Selhausen
  • Phil Hunt
  • Takahiko Kawasaki
  • Aaron Parecki
  • Brian Campbell (Ping Identity)
  • Cristofer Gonzales
  • Jeff Craig
  • Peter Yee
  • Vittorio Bertocci
  • Mike Jones
  • George Fletcher
  • Bjorn Hjelm
  • Andrei Stebakov

Recording

https://ietf.webex.com/recordingservice/sites/ietf/recording/aa36b73bd741462386fc5e6f38c353c1/playback

Next Interim Meetings