7B/ Mind The GNAP - Delegation beyond OAuth / Justin R

From IIW

Session 7B

Mind the GNAP


Session Convener: Justin Richer

Notes-taker(s): Dean Saxe

Tags / links to resources / technology discussed, related to this session:


https://www.ietf.org/archive/id/draft-ietf-gnap-core-protocol-11.html


Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:


  • delegation protocol similar to OAuth
    • built on similar mechanisms as oauth
  • Justin and team looked at OAuth + OAuth like things + UMA + extensions to OAuth to drive thinking about GNAP
  • There is no plan for wire compatibility with OAuth with GNAP
    • it is NOT OAuth 3
  • What does the room want to hear?
    • What does “delegation” mean in GNAP? Is GNAP allowing a user to delegate access to another?
      • GNAP allows delegation from a resource owner to a client instance
      • In GNAP the end user is a separate entity
      • The end user is the user using the client instance, they are usually the resource owner
      • GNAP does NOT cover any way to connect the end user and resource owner together - there is no definition of how you set up that ***policy/mechanism
      • talking about the RA and end user as separate entities gives flexibility in the protocol
      • GNAP enables use cases where the right of authority comes from both the resource owner (RO) and End User
        • but the delegation is outside the scope of GNAP
        • OAuth2 covers a single user case
      • In the cases where RO and end user collapse to a single person, it is supported directly by the protocol
      • in GNAP every single request starts the same way
    • Adrian Gropper - The lack of connection between the RO and end user is essential in our health use cases
    • GNAP is not delegation between users - it’s between person and software
    • Section 1.6 of the spec - async authZ diagram on the screen
      • from a protocol perspective GNAP presents a menu of options
      • client says “this is what I can do, this is what I want”
      • authZ server says “this is what I can do and will allow”
      • there’s a dynamic negotiation/conversation happening
      • Client requests access from the AS
      • AS responds with a wait message
        • the AS can map the client request to who can authorize the request
        • the client polls the AS until access is granted (or denied)
      • Note that the client is saying it has no idea how to contact the RO
        • the AS instead does this on behalf of the client while the client waits
        • the AS can decide what is the best approach for contacting the resource owner
    • Can the client host the AS? Or is it typically hosted elsewhere?
      • Justin - these are roles in the system fullfilled by some software, so they can all run on the same service
    • This is a protocol for effectively generating a limited scope API key in response to a request
    • GNAP separates the AS, RO, RS, etc as roles
      • the AS knows about people, processes, policies and how to generate an access token
      • the RS has to know how to understand the access token and what is being communicated
      • GNAP does not specify how the AS and RS are tied together
      • there’s another draft addressing this mechanism, it is not in the core doc
    • CIBA Example
      • call center example
      • end user and RO are different
      • as a call center agent you need to access information about someone else in the system
      • client instance makes request to AS “this is my current user, client software, and user the client wants data about”
      • the driving use case here is a user in a call center receives a call
        • user asks to view a set of info on the caller
        • caller gets a push notification on the app requesting access
        • caller approves
        • the interactive approval via a trusted channel allows the call center user to see the customer’s data
  • In the protocol the client asks for something at AS with a four part request in a JSON doc
    • First section: API Access
      • grant requests have a rich set of data that can be requested that is defined by the AS
    • second section: Info about the client
      • client send name, URI, and key information
    • Third section of the request says how the AS can interact with the client for starting and finishing the interactions
      • multiple starting mechanisms
      • one, and only one, finish mechanism
    • fourth section: subject info
  • Response from the AS for a redirect flow
    • two part response in JSON
      • interact - tell the client to go to a URL with a nonce
      • continue - here’s a URL and access token to call the URL
        • the token is presented signed by the client key
        • this ensures that only the client is able to call the AS as a part of this request
  • in GNAP the client is stupid - all the intelligence in the system is within the AS
  • message binding
    • in the grant request the client send a pub key to identify itself
    • that same key is used by the client to create an HTTP message signature
    • the sig headers are added to the top of the grant request
    • this allows the AS to pull out the key to verify the sig on the message
    • this ensures message integrity, the method and target URI have not been manipulated, etc.
    • the AS is then clear that the client made the request
    • HTTP Message sig is not the only mechanism, JOSE could be used as well
    • similar message binding is used for the RS, as well
      • unless you opt out and get a bearer token to talk to a RS
  • finish message allows the client to tell the AS that the interactions have been completed
Retrieved from "https://iiw.idcommons.net/index.php?title=7B/_Mind_The_GNAP_-_Delegation_beyond_OAuth_/_Justin_R&oldid=24657"