* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Oauth Status Pages

Web Authorization Protocol (Active WG)
Sec Area: Eric Rescorla, Benjamin Kaduk | 2009-May-13 —  
Chairs
 
 


IETF-103 oauth minutes

Session 2018-11-05 0900-1100: Meeting 2 - Audio stream - oauth chatroom
Session 2018-11-06 1120-1220: Meeting 1 - Audio stream - oauth chatroom

Minutes

minutes-103-oauth-00 minute



          # 1st OAuth meeting at IETF 103, 5-Nov-18
          
          Notetaker: Christopher Wood
          
          ## Introduction (Hannes)
          https://datatracker.ietf.org/meeting/103/materials/slides-103-oauth-sessb-chair-slides-01
          
          
          ## Token Binding (Brian) - draft-ietf-oauth-token-binding
          https://datatracker.ietf.org/meeting/103/materials/slides-103-oauth-sessb-draft-ietf-oauth-token-binding-00
          
          
          Torsten: option 3 (slide 7) is the pattern for native apps or OAuth
          client that preflights requests?
          
          Brian: Sort of, but only applicable to browser-based clients. Probably
          could not do it in native clients.
          
          Torsten: We probably need some text describing how implicit binding
          works for native apps.
          
          Brian: Should be there currently, could probably be improved.
          
          Mike Jones: Part of the issue is that there is no standard token binding
          API for fetch? Some Google folks worked on a PR in WhatWG for that,
          but not sure what the status is.
          
          Brian: Not sure how to answer since it depends on what the fetch API
          might provide, and whether or not it addresses this use case.
          
          John Bradley: Has been some work on fetch, though the problem is that
          browsers are trying to foil us fighting ad networks. Will probably be
          limitations in what tokbind origins are specified in fetch. May need to
          look at other options for single page apps, e.g., WebCrypto.
          Browsers may not be as cooperative as one would hope.
          
          Hannes: options (1) and (2) would be unsatisfactory for this document.
          
          Brian: Maybe we can remove implicit flows as we did with MTLS?
          
          Torsten: Statement is true if javascript clients always use implicit?
          
          Brian: Wouldn’t work with code flow
          
          Hannes: How do we resolve this?
          
          Brian: Future use and validity of this draft is in question now.
          
          Torsten: Conclusion is that we can’t protect SPAs using token binding?
          
          Brian: Might not be that black and white, but it is difficult. There
          are a lot of conditions.
          
          Ben: Is question that we cannot currently support SPAs, or that we cannot
          ever do that?
          
          Brian: Both. Even with support from browser vendors, the result might
          not support cross-domain use case with issues surrounding tracking.
          
          Dirk: Aren't there other use cases for token binding? There are other
          flows where token binding provides value.
          
          Brian: Without browser support, unlikely to see widespread API support
          for this draft. There’s not much incentive.
          
          John: Can we achieve critical mass without broad support in the
          browsers? Will people support TLS implementations to support this?
          
          Annabelle: Wonder how much focus is on browsers is premature. It’s
          hard to imagine people using token binding given lack of infrastructure
          support for it.
          
          Hannes: Have discussion about whether or not to remove implicit use case
          now?
          
          Torsten: Can we postpone until after my presentation?
          
          Brian: Only wanted to raise the issue for now.
          
          Dirk: Architecturally there may be a preferred solution, but we should
          survey what’s out there to see what’s viable or not.
          
          ## OAuth Security Topics (Torsten) -- draft-ietf-oauth-securtity-topics
          https://datatracker.ietf.org/meeting/103/materials/slides-103-oauth-sessb-draft-ietf-oauth-security-topics-01
          
          
          Ben: do we need to write an implicit flow diediedie draft?
          
          Brian: Maybe have BCP recommend against it to start.
          
          Mike: Maybe not try to kill something, but try to describe security
          considerations about when we do and do not need to use a feature
          
          Hum: use authorization code instead of implicit flow (Room in favor)
          
          ## JWT Introspection Response (Torsten) --
          draft-ietf-oauth-jwt-introspection-response
          https://datatracker.ietf.org/meeting/103/materials/slides-103-oauth-sessb-draft-ietf-oauth-jwt-introspection-response-00
          
          
          Jim: Partially answered question about why we’re not allowing JWT
          requests in addition to responses to hide things such as referrals
          
          Torsten: What would we achieve by adding a nonce to the request?
          
          Jim: Worried about cases where there are multiple servers in the
          backside.
          
          Torsten: Typically use a nonce for replay protection? We rely on TLS
          for replay detection.
          
          Torsten: RS knows which AS it is talking to, and TLS is used to talk to
          it. Learning which AS to talk to is not part of this use case.
          
          Torsten: Should we generalize this draft to all types of responses?
          
          Jabber: This draft needs to be clear about encrypting results/responses
          to a key. (?)
          
          Annabelle: (missed)
          
          Mike: Already have OpenID draft for signed OAuth responses. Doing that
          in this draft to doesn’t make much sense?
          
          Torsten: Will cover in next presentation.
          
          Justin: This is for the front-end channel (?)
          
          Brian: Trying to generalize in a single draft may be more academic
          than useful. Do not see a really use case for it in revocation
          responses. Against generalizing it in that fashion.
          
          ## JARM (Torsten) -- openid-financial-api-jarm-wd
          https://datatracker.ietf.org/meeting/103/materials/slides-103-oauth-sessb-openid-financial-api-jarm-wd-01
          
          
          Annabelle: mis-characterized response mode — it does not define
          different representations, it defines different transport mechanisms.
          Query, fragment, and form post have been standardized. Representation of
          response in all of those is as a URL-encoded query string. Its placement
          in the request varies across these. Makes sense to see this as an envelope
          type. Are you mandating as part of spec that the JWT is transmitted via
          a particular manner?
          
          Torsten: Transmitted as part of form post.
          
          Annabelle: Do think it’s worth pursuing this work in OAuth. Subject
          matter expertise will be be found here, especially with respect to how it
          plays with other specs. Could look a this as a response format parameter?
          
          Torsten: Proposing combine response mode with new encoding/format?
          
          Annabelle: They are separate things.
          
          Justin: Not against this work but would like how many things are we
          willing to reinvent before we admit we’re doing HTTP?
          
          Mike: Against complexity when not necessary.
          
          Matthew: Interesting work, good to do here.
          
          Annabelle: Determining were to put parameters in request depends on
          the scope of the work. Might need to make sure that response parameters
          do not conflict wit JWT. Applying to other (existing) protocols where
          avoiding collisions may not be practical might be hard.
          
          Mike: Do not want a third parameter called response format where knowledge
          of three parameters is necessary to encode/decoded JWT.
          Developers will certainly get that wrong.
          
          Brian: Agree with Mike. Seems to mix encoding format and response
          mode. Possibility of combinatorial explosion is there, but may not happen
          in practice.
          
          Hannes: Good feedback about how this could be used beyond financial APIs,
          so maybe write up a draft for the group?
          
          Torsten: Or we could circulate a pointer to a document written elsewhere.
          
          ## PoP Key Distribution (Hannes) -- draft-ietf-oauth-pop-key-distribution
          https://datatracker.ietf.org/meeting/103/materials/slides-103-oauth-sessb-draft-ietf-oauth-pop-key-distribution-00
          
          
          Jim: Should we issue two access tokens with different permissions, and
          put a KeyID in req_cnf? We can rewrite to use the refresh token without
          issues.
          
          # 2nd OAuth meeting at IETF 103, 6-Nov-18
          
          Notetaker: Mike Jones
          
          Brian Campbell - draft-ietf-oauth-resource-indicators
                        See presentation at
                        https://datatracker.ietf.org/meeting/103/materials/slides-103-oauth-sessa-resource-indicator-00
          
                        The draft has been updated to align it with OAuth Token
                        Exchange
                        It now allows query parameters in the URL
          
                        Mike Jones asked the chairs about Working Group Last Call
                        (WGLC)
                        Hannes asked who had read the document
                                     About 10 people had
                        Justin asked about the possibility of confusion between
                        scoped and resources
                                     Brian didn't believe that Justin's comment
                                     was particularly actionable
                        Torsten went to the microphone to express support for WGLC
                                     He stated that he believes what's in the
                                     draft is a pragmatic approach
                        Hannes said that the chairs will send a WGLC announcement
                        to the working group
          
          Brian Campbell - draft-ietf-oauth-mtls
                        See presentation at
                        https://datatracker.ietf.org/meeting/103/materials/slides-103-oauth-sessa-mtls-00
          
                        Has gone through WGLC
                        Drafts -10, -11, and -12 addressed WGLC and developer
                        feedback
                        The Area Director (AD) review came in yesterday
                        Brian talked about potential support for Subject Alternative
                        Name (SAN) in addition to Subject DNs
                                     Mike Jones asked whether specifying
                                     multiple mechanisms will hurt interop of
                                     implementations
                                     Ekr asked whether people would advocate
                                     Subject DNs in a greenfield situation
                                     John Bradley said that here is no greenfield
                                     situation - there's plenty of X.509 legacy
                                     in play
                                     ... In Dynamic Client Registration, how do
                                     you specify what would be matched?
                                     ... European EIDAS certificates have custom
                                     extensions - do we try to match those?
                                     Brian: These choices very much imply a client
                                     data model
                                     Torsten: I agree that this is about matching
                                     at dynamic client registration time
                                     Brian would like to do something pragmatic
                                     and functional
                                     ... We can't account for all possible cases
                                     Torsten: We could define a registration
                                     parameter per SAN
                                     ... We could even define one for EIDAS
                                     matching
                                     Ekr: Managing DNs has proved to be exceedingly
                                     difficult
                                     ... That's the reason we have been moving
                                     towards SAN
                                     ... Pick one kind of SAN - We don't have to
                                     define all the alternatives
                                     Mike asked whether there were use cases for
                                     mutual TLS with SANs
                                                   Brian responded that the SPIFFY
                                                   (sp?) folks are doing this
                                     Brian suggested adding this capability to
                                     the document
                                     John: The authorization server will be the
                                     party doing the matching
                                     ... The server could specify what kinds of
                                     certificate fields it can match
                                     Hannes cut discussion on this topic due to
                                     time - we will take it to the list
                        Brian asked about privacy considerations for sending
                        certificates in the clear in TLS 1.2
                                     Ekr said that that wasn't discussed in TLS
                                     1.2 - we should probably add a few sentences
          
          Dick Hardt - draft-ietf-oauth-distributed-oauth
                        See presentation at
                        https://datatracker.ietf.org/meeting/103/materials/slides-103-oauth-sessa-distributed-oauth-00
          
                        Asked about link headers versus www-authenticate header
                                     Many existing libraries just pass
                                     www-authenticate header information through
                                     Mike Jones spoke in favor of continuing to
                                     use www-authenticate
                                     Dave Robin also spoke in favor of the use of
                                     www-authenticate headers
                                     Hannes and Benjamin suggested also asking the
                                     question to the httpauth@ietf.org mailing list
                        Dick asked whether to use a full discovery URL or the
                        issuer value
                                     Torsten spoke up in favor of the full URI
                                     Mike spoke up in favor of using the RFC 8414
                                     issuer
                                     Hannes said that we need to discuss this
                                     issue on the mailing list
          
          Dick Hardt - draft-ietf-oauth-reciprocal
                        See presentation at
                        https://datatracker.ietf.org/meeting/103/materials/slides-103-oauth-sessa-reciprocal-oauth-00
          
                        Dick is seeing use cases in which two interacting parties
                        are both clients and protected resources
                        ... We have deployed this in Alexa
                        We discussed what the proposed "reciprocal" Token Endpoint
                        response value means and how it relates to scopes
                                     Mike asked for clarification of the intended
                                     semantics
                                     Annabelle clarified that "reciprocal" is the
                                     scope that the other party would request
                                     John said that it is the requested scope in
                                     the response
                        Hannes asked for reviewers
                                     Mike, Torsten, and Matt Miller volunteered
                                     to review the document
          
          Omer Levi Hevroni - draft-hevroni-oauth-seamless-flow
                        (Omer presented remotely - no presentation is in the
                        datatracker)
                        (The audio was nearly unintelligible)
                        Omer is looking for comments on his draft
                        Hannes: Do you have deployments or implementations?
                                     Omer: Yes
                        Hannes: Nobody in the room has read the draft
                        Hannes asked for reviewers
                        Torsten and Dick volunteered to review the draft
          
          Aaron Parecki - draft-parecki-oauth-browser-based-apps
                        (Aaron attempted to present remotely but there was no
                        audio and we were 5 minutes over time)
                        Hannes asked for reviewers
                                     Matt, Torsten, and John volunteered
          
          



Generated from PyHt script /wg/oauth/minutes.pyht Latest update: 24 Oct 2012 16:51 GMT -