# 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](https://datatracker.ietf.org/meeting/interim-2021-oauth-04/materials/slides-interim-2021-oauth-04-sessa-oauth-session-rar-542021-00) # 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 * April 12 Security BCP – Daniel https://datatracker.ietf.org/doc/draft-ietf-oauth-security-topics/ * April 19 Identity Use Cases in Browser Catalog – Vittorio/George https://datatracker.ietf.org/doc/draft-bertocci-identity-in-browser/ * April 26 TMI BFF – Vittorio/Brian https://datatracker.ietf.org/doc/draft-bertocci-oauth2-tmi-bff/ * May 3 OAuth 2.1 - Aaron https://datatracker.ietf.org/doc/draft-ietf-oauth-v2-1/