* 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, Kathleen Moriarty | 2009-May-13 —  

IETF-99 oauth minutes

Session 2017-07-18 1330-1530: Berlin/Brussels - Audio stream - oauth chatroom
Session 2017-07-21 0930-1130: Karlin III - Audio stream - oauth chatroom


minutes-99-oauth-01 minutes

          OAuth minutes
          **** 13:30-15:30        Tuesday Afternoon session I ***
          Scribe: Neil Jenkins
          Last week there was an OAuth security workshop in Zurich. Info available
          at https://zisc.ethz.ch/oauth-security-workshop-2017/
          JWT Secured Authorization Request - now in IESG evaluation, comments
          have been taken onboard. It's taken a while - some reasonably
          substantial comments to deal with. An updated version of the spec will
          be uploaded very soon.
          ## Mutual TLS Profile for OAuth 2.0.
          Now in draft 2. Should not require major changes for implementation.
          Hoping to go to working group last call soon. Approx 6 people in the
          room have read the previous draft.
          Comment: More algorithm agility needed; we should not hardcode use of
          SHA-256. Answer: We can define new algorithms later with a new claim
          name. Would need to register a new confirmation method under RFC7800.
          Comment: An example would be good to show this in the spec. Will an
          upstream registration be sufficient? If a new hash algorithm is defined
          as a new confirmation method, it will flow down to JWT as well as
          Comment: Also how can the certificate be transmitted as part of this? It
          can't at the moment. Answer: we decided to use the fingerprint because
          we just want to be able to verify that the sender is in posession of the
          certificate. The validation of the certificate is up to the TLS spec.
          Comment: Did you consider using hash of public key info instead of whole
          certificate? This is what's used in certificate pinning. This allows the
          hash to stay the same if you reissue the cert, e.g. for a new expiration
          date. Answer: the current solution seemed the most straight forward.
          Didn't seem to big a burden to require clients to obtain new access
          token if certificate reissued.
          Comment: Short term certs (e.g. Let's encrypt) – you wouldn't want to
          have to reissue access tokens that frequently. Counter-argument: access
          tokens should be max 1h lifetime, so this should not be an issue.
          Comment: Several assumptions have been stated. e.g. Tokens need to be
          refreshed every 5min-1h. If draft is based on these assumptions, they
          need to be in the spec.
          Comment: In the JWS spec, where X5T is defined, it already gives an
          example of how you would define one with new hashes. Can reference this
          rather than repeating it. Don't define something just for the purpose of
          defining it if it's never going to be used.
          Conclusion: Doesn't seem to be too far fetched to go to WG last call
          soon. Torsten will review. Justin will also be reading in depth. Paul
          Grassi volunteered as well.
          ## Access tokens phishing
          Mic drop. What a way to begin.
          OAuth being used in context which is not web APIs. Assumptions in
          original spec do not always hold.
          Client wants to access RS via Standard API. Client is configured with RS
          URL at runtime. This is a change to the OAuth trust model.
          What if... The resource server is a bad guy? Could take the access
          token and proxy through to the real resource server. The client would
          never know.
          What can we do? What if the client would know upfront which place is
          save to send access tokens to? AS can return list of allowed resources.
          But this puts the burden on client develops to keep secure. Since there
          are more clients than servers, would be more robust to enforce at the
          server level. Experience shows authors often get this wrong.
          Can restrict access token to specific URL. Client has to ask for an
          access token for a specific URL using the "audience" field. Could also
          use the TLS certificate fingerprint. AS will refuse to issue token, or
          even if it does it will not be valid when proxied to real RS.
          Objections: AS may not know all the valid RSs. RS may be split across
          multiple domains.
          Comment: Issues with using cert: in a heavily distributed environment,
          there may be a nunber of valid certs. Also cannot get cert from web
          browser, so could not be used in web apps.
          Proof of possession. Client obtains cert, signs request with cert and
          includes the URL in the audience. Related to token binding/MTLS at
          transport layer or signed request/jpop at application layer.
          So... what should the BCP recommend?
          Clarification: jpop refers to the application side of it. Comment: there
          are use cases where access tokens are needed to be used with multiple
          resource servers, and the URLs are not even known at time of issuance.
          There also may be multiple certs.
          Comment: different mechanisms have different threat models. One is about
          stoping wrong receiver from getting token. But we are really worried
          about the wrong client using the token. The more direct mechanism to
          address this threat is the proof of possession.
          Comment: Amazon is using audience restriction with URL.
          Comment: Advantage of audience restriction is it doesn't require clients
          to do new crypto, so is easier to implement.
          Comment: there are benefits to indicating where you want to use the
          access token (audience restriction); may return different access token.
          Comment: deploying MTLS is a huge pain in the ass. Will probably only
          happen for banks and other enterprise-level niche deployments. Token
          binding very early days; remains to be seen if it will be widely
          adopted. Application binding is really hard to get right, and be
          Conclusion: Audience restriction seems to be the least worst option.
          We will still pursue MTLS/Token Binding, but may not sufficient for
          immediate needs. More discussion on the list needed.
          ## OAuth 2.0 Incremental Auth
          Asking for access to everything up front is bad. Users should have
          context of auth request. Better: the ability to request additional
          scopes in subsequent requests resulting in a single grant representing
          all scoopes granted so far.
          Consent screen should only display new scopes. Single refresh token
          issued for the union of all scopes. OAuth 2.0 does not stop this, so
          many people have implemented this already for confidential clients.
          Comment: why not sending refresh token with auth request? Will be
          answered later.
          Threat model: Mail client gets mail scope. Illigitemate app impersonates
          other app. Requests other scope, gets both back.
          Implementation details: existing grant must be valid in its own right.
          Client ids must match.
          * Could also pass previous grant in the auth request. Can't do this
            because would be passing it in a GET request.
          * Use access token as proof of existing grant. Drawback: more
            susceptible to attack.
          Google's OAuth server already supports incremental auth for
          public clients.
          Comment: Second request asks for user to choose account. Is this
          neccessary? Answer: no, we support openid connect, so can pass username
          in second request.
          Question: Do you detect if the user account is different between to
          previous request? Yes, that needs to be validated too.
          Comment: incrementally adding profiles over time means users may not
          notice how much access the client is building up about them. Useful for
          profiling; privacy concern. Answer: you could do this attack without
          incremental auth, just by getting 10 separate tokens instead of 10
          incremental ones. This just makes it more developer friendly.
          Comment: it's not transparent to the end user that it is additive and
          that revoking any one scope will now revoke all. (User may grant just
          one extra access scope, but then want to remove just that scope.)
          Answer: this is an implementation details.
          Comment: better UI to show what's already been granted as well as what
          extra is being requested.
          Comment: The term "auth" is ambiguous in spec name.
          Comment: Should indicate in the authentication request which instance of
          the client is making the request, so you can revoke e.g. on your phone
          but not your computer.
          Demo code only available for iOS at the moment. A bit premature to do
          call for adoption, but topic is in scope. More feedback needed.
          Please read and review. Torsten, Nat, and John volunteered.
          ## JSON Web Tokens Best Current Practices
          Early draft still. JWTs often depolyed insecurely, but are now being
          used in many IETF protocols.
          Please review and discuss content, particularly as it applies to your
          use cases.
          About 10 people in the room have read the document.
          Comments: Definition of "typ" is toothless. Have you considered doing
          something at the JOSE layer? Answer: concern not everyone is
          implementing "critical" correctly. It's not clear this will be better.
          Comment: new profile could define use of "typ" in such a way that use
          against old profile would break without old profile having to know about
          new profile. Will be taken to list.
          Comment: are some of these points actionable real things? e.g.
          compression. Or is it just FUD? Deprecating some profiles of RSA? We
          should get expert review. It's bad news if you get stuff wrong: only
          compress if you've carefully reviewed that this usage is safe.
          Comment: PKCS 1/1.5 used TLS BCP to opinionate about algorithms, so it's
          legit to do in this draft.
          Should the work be adopted in this group? A clear "yes" consensus from
          the room. If not already in the charter, will fix this soon.
          Brian volunteered to review.
          **** 9:30-11:30 Friday Morning session I ***
          Scribe: Mike Jones
          William Denniss presented on the Device Flow
          Justin Richer discussed a suggestion to add another parameter that he'd
          made on the list
          William Denniss clarified that the client constructs the URL - not the
          Justin withdrew his suggestion
          Justin will review the text and suggest clarifications to help people
          from misunderstanding it in the way that he did
          Annabelle Backman suggested that there be a separate parameter that
          contains the clickable URL
          Annabelle suggested that there be a separate parameter for that URL
                        Then we don't have to standardize the URL for the user_code
                        It would allow the server to use a different URL for that
          Dick Hardt suggested that the user code be URL safe
          Annabelle:  People implementing clients may not always be reading the
          David Robin: There's an opportunity to send people straight to the final
          Nat Sakimura: Our implementation sends both the URL and the user_code
          Nat: It's easier to enter Japanese characters than ASCII in Japan
                        We should allow the code to be Unicode
          Dick Hardt:  Amazon recently looked at what can be entered world wide
                        He said that numbers work really well
          William:  Maybe we can suggest that numbers be used as a best practice
                        I do not want to prevent the use of letters because it
                        would bring our implementation out of compliance
          Mike Jones:  Microsoft also uses letters in the codes
          Nat:  If we are targeting QR codes, send the QR code directly
                        QR codes are used on ATM machines in Singapore and
                        If it's going to be an image, it should be a separate
          Annabelle:  Trying to tailor the spec to particular delivery mechanisms
          would take us down a huge rathole
          Dick:  It's not clear we're really trying to achieve interop
          William:  Justin and I did interop testing with both of our
          Dick:  Amazon is using independently written implementations
                        In the Alexa world, there are many third parties producing
                        devices that we want to be able to make calls into Alexa
          John:  I am influenced by the arguments that having a different endpoint
          for the pre-composed URL than the user typeable one is a good idea
                        I don't know that we should add the QR code directly
                        Apps could use introspection to get a QR code or sound
                        files but that doesn't have to be in the standard
                        Third party clients operate with YouTube and other services
          William:  There are two changes we're discussing
                        1.  Having a second endpoint for the pre-composed URL
                        2.  Saying that the user code should be URL safe, with
                        numbers recommended
          William:  If we make it Unicode, we should use a different URL
          Mike Jones:  Adding a separate endpoint is a big change
          John:  The change is to have a separate parameter for the composed URL -
          not a separate endpoint
                        Anything internationalized immediately leads us to sending
                        a composed URL
                        Using a different endpoint is an implementation choice -
                        not something for the spec
                        The client needs to know the script that it's going to
                        A Korean printer might use Korean script in Korea but a
                        different script in South America
          Nat:  Numbers are the best choice internationally
          Annabelle:  The more complicated we make the display requirements,
          the more use cases we'll exclude
          John:  UTF-8 may not be displayable on all devices and the right fonts
          might not even be installed
          Annabelle:  We are suggesting a new parameter with a URL value - not a
          new endpoint
          Leif Johansson:  Has anyone done a security analysis on this?
                        We shouldn't do these changes without another last call
          David Robin: Are we deprecating what's shown on the screen or is that
          option still on the table?
                        (On the screen, the client was shown merging the different
                        pieces of information)
                        Maybe client composition should never be done
                        It's either opaque with the third parameter or you need
                        to do composition the way the draft is now
          Annabelle:  The current draft does describe Security Considerations
          about remote phishing
          William:  We try to prevent phishing by asking the user if they have
          the device in their possession
          Lucy Lynch:  These are big enough changes to require another working
          group last call
          William:  There's no requirement that you poll at any particular rate
          Mike Jones:  From an engineering perspective, why do people want to do
          things differently than what's currently specified?
          Dick:  We looked at this and saw some of the issues
          William:  The other major change being considered is defining new
          authorization parameters
                        device_id, device_model, device_name
                        This is to support device revocation
                        They are all optional
          Annabelle:  This does not seem unique to the device flow
          William:  I agree but it's worth solving for the device flow
          Annabelle:  If we're overly prescriptive with what information is being
          sent, we could end up ruling out use cases we haven't thought of
          Hannes Tschofenig:  This came up in Chicago
                        We might want to do some form of authentication
                        These parameters are intended for revocation, but they
                        could be used for authorization as well
          William:  I'm not trying to capture every possible parameter for every
          use case
                        Google does have use cases for these parameters
          Dick:  The device ID is problematic
                        The other two new parameters are useful
          William:  The device ID lets the authorization server group requests
          Annabelle:  If this is happening at the AS, it could assign an ID on
          its own
          Annabelle:  Model and name present a potential phishing risk
          Hannes:  The AS can't infer the device name
          Annabelle:  The AS should match the client ID to the device type
          William:  If we add these parameters we need to add Security
          William:  We shouldn't enable display of random hacker-generated text
          Dick:  The model allows multiple different things on a device
                        For instance, enabling Netflix on your Roku - not just
                        enabling the device
          John:  Device ID is a correlatable identifier
                        Some manufacturers go out of their way to prevent multiple
                        applications from knowing that they're on the same device
                        This is its own thing and should be in its own spec
                        Let's finish the device spec and consider this a separate
          Lucy:  I think that John summarized this correctly
                        I could drive a truck through this
          Hannes:  The context of this spec made discussing these possible
          parameters reasonable
          Justin Richer:  This loops back to Mike's question about why people are
          bringing this up now
                        People have been implementing something like this for years
                        Now people are reviewing the spec and asking if it fits
                        the use cases they've had for years
                        We are seeing more and more devices where this functionality
                        makes sense
                        I think this should be a separate spec
                        I wrote such as spec in 2010 draft-richer-oauth-instance-00
                        This has applicability in other places and it's a big ball
                        of wax
                        It's too much to try to slip this in at the last minute
          Brian Campbell:  Maybe we could accomplish this without device ID
                        We would lose grouping but that would alleviate a lot of
                        the privacy concerns
          Dick:  You only need a locally scoped identifier
                        The global one is the one that's a problem
          William:  There is running code
                        Google's implementation complies with -06
                        MitreID implements it
                        Justin and William did some interop
          Hannes:  There are other open source implementations
          Brian Campbell presented on OAuth Token Exchange
          It is a framework enabling token exchange
          The participants need to know what kinds of tokens are suitable for
          their use cases
          Draft -09 included small changes to address actionable WGLC feedback
          Hannes will review feedback that didn't appear to be actionable
          Brian believes it's ready for Hannes' write-up
          John:  Write it up
          Brian Campbell presented on OAuth Token Binding
          Provides proof of possession for OAuth tokens
          The 3 core Token Binding specs are very close to the request for
          The last OAuth Token Binding spec version added introspection language
          and IANA registrations
          Brian added an open issue about the need to allow distributed Web Server
          clients to opt out of token binding for refresh tokens
                        Shared access to a public key may be difficult or impossible
                        Sharing on demand generated client-side keys is very hard
          Dick Hardt:  It's not going to happen
          Brian:  The real value is Token Binding the access token
                        There are other means of securing the refresh token
          There are two ways we could do this
                        Toggle the behavior based on client registration metadata
                        Or provide a run-time toggle with a parameter
          The metadata parameters already largely exist
          Mike Jones:  I think the metadata approach is reasonable
                        I don't want to think about the security implications of
                        providing a parameter to disable a security feature at
          Brian:  I think the metadata approach is reasonable
          John Bradley:  I agree with using metadata
          John Bradley:  As a separate issue, we may eventually decide we need a
          parameter to explicitly communicate the referred token binding separately
          from the Sec-Token-Binding header
                        There are more discussions needed on the parties using
                        the bound tokens
          William Denniss:  Is this only for confidential clients?
                        Brian:  Yes
          William:  We don't want to encourage people to opt out very often
          John:  We do have a mutual TLS option so there are more than one ways
          to achieve proof of possession
          William:  Authorization servers could say that access token binding is
          Brian:  Should the scope include standardization of Token Binding for
          JWT Client Authentication for RFC 7523
          John:  We should write this down because it's only self-evident how to
          do this to a very small set of people
          Brian:  We would write down how to use the cnf/tbh claim in the context
          of RFC 7523
          Hannes:  Please write this down
          Brian:  We need to remove the reference to the expiring resource metadata
          Brian:  I have ideas how to keep the intent but simplify
                        We would still describe how to detect and respond to
          Brian:  This is still early
                        Client library support is still sparse
                        We have things to learn from deployments
          Dick:  Is pushing Token Binding through to the end-application after
          TLS termination in scope?
          Brian:  No, but the Token Binding WG just accepted a document about this
          Dick:  This doesn't provide the same guarantees as other application-layer
          PoP mechanisms
          Brian:  This relies upon trust between the TLS terminator and the
          Brian:  I don't know a way to tightly bind this end-to-end
          Dick:  The verification is happening at the application
          Dick:  I believe that Microsoft is encrypting the token
          Dick:  The problem is that the TLS terminator is in a different trust
          domain than the application
                        It's trusted to terminate TLS but not to manage the token
                        or do authentication or authorization
          Dick:  What's being done in the Token Binding working group doesn't
          solve this problem
          John:  I asked Tony Nadalin to provide information about this
                        Including the possible use of additional Token Bindings
          Andrei Popov:  I'm not familiar the higher-level functionality being
                        If you're terminating TLS, that's where end-to-end ends
                        for TLS functions, such as Token Binding
                        You're trusting that the TLS terminator is passing correct
                        information to you
          Hannes:  We need to update our OAuth PoP documents
                        End-to-end PoP is definitely in scope for the OAuth WG
          Dick:  You didn't solve anything
          Dirk Balfanz:  It sounds like you already have a proof-of-possession
          Dick:  We have a non-standard way in which Amazon API calls are made
                        There is a secret, you sign the request, and it's verified
                        at the application level
          Hannes:  Is it HTTP signing?
          Dick:  Yes
                        It prevents a compromised TLS proxy from changing the
          Justin Richer:  I did look at the Amazon spec when writing the OAuth
          HTTP signing spec
                        There were lots of problems with parameters being reordered,
                        etc. in OAuth 1 implementations
          Hannes:  I would like Dick to look at the current OAuth HTTP signing spec
                        Maybe that will solve the issue that Dick is describing
          Dick:  That doesn't build on Token Binding
          Justin:  They are orthogonal
                        You could do both Token Binding and application-level PoP
          Dick:  What I like about Token Binding is that you don't have to do
          client-side management of a key
                        Token Binding lets you get many of the characteristics of
                        PoP without client-side key management
          Hannes:  What are the right next steps for this issue?
          Dick:  I want Token Binding with end-to-end guarantees
          Dick:  Most of our deployments have TLS proxies
          Brian:  This isn't in scope for this document because the problem isn't
          specific to OAuth
          Brian:  This is also applicable to Token Bound cookies
                        The same issues occur for cookies

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