Re: [OAUTH-WG] OAuth Working Group Meeting at IETF 99 21-Jul-17

Justin Richer <> Fri, 21 July 2017 15:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E5F1E13178B for <>; Fri, 21 Jul 2017 08:55:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id haFRjG1WQ6DG for <>; Fri, 21 Jul 2017 08:55:10 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B3B53131935 for <>; Fri, 21 Jul 2017 08:55:09 -0700 (PDT)
X-AuditID: 1209190e-69dff70000004181-02-597223da7f21
Received: from ( []) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id 64.05.16769.BD322795; Fri, 21 Jul 2017 11:55:07 -0400 (EDT)
Received: from (OUTGOING-AUTH-1.MIT.EDU []) by (8.13.8/8.9.2) with ESMTP id v6LFt577029138; Fri, 21 Jul 2017 11:55:06 -0400
Received: from artemisia.richer.local ( []) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by (8.13.8/8.12.4) with ESMTP id v6LFt4jP030719 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 21 Jul 2017 11:55:05 -0400
From: Justin Richer <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_1FD25D9D-429D-4AA2-862D-7E9DA0540A50"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Fri, 21 Jul 2017 11:55:03 -0400
In-Reply-To: <>
Cc: "<>" <>
To: Mike Jones <>
References: <>
X-Mailer: Apple Mail (2.3273)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrAKsWRmVeSWpSXmKPExsUixG6nontbuSjS4PxnIYu90z6xWJx8+4rN gcljyZKfTB6tO/6yBzBFcdmkpOZklqUW6dslcGX0HzQu2LGYpWL2wX72BsYXl5i7GDk4JARM JGZd8ehi5OIQEljMJDF3128WCGcjo8S10z9YIZyHTBLLP8xm72Lk5GATUJWYvqaFCcTmFbCS mHm0lRXEZhZIktg/+y4jyFReAX2J3ueMIGFhAQ+JBe9mgpWzALU+ejgHzOYUiJU4vuUcWDmz gLpE+0kXkLCIgI7E44vf2EBsIYEYia5VD1lAbAkBWYlbsy8xT2Dkn4Vk2SyEZRBhbYllC18z Q9iaEvu7l7NgimtIdH6byLqAkW0Vo2xKbpVubmJmTnFqsm5xcmJeXmqRrrFebmaJXmpK6SZG UFBzSvLtYJzU4H2IUYCDUYmH14ClKFKINbGsuDL3EKMkB5OSKO/ddYWRQnxJ+SmVGYnFGfFF pTmpxYcYJTiYlUR4mwSAynlTEiurUovyYVLSHCxK4rziGo0RQgLpiSWp2ampBalFMFkZDg4l CV5BJaBGwaLU9NSKtMycEoQ0EwcnyHAeoOGhIDW8xQWJucWZ6RD5U4z2HJtm/PzGxPFqwn8g eej3ie9MHMdApBBLXn5eqpQ4b7oiUJsASFtGaR7cZFDCSnh72PQVozjQo8K8WSDDeYDJDm72 K6C1TEBrH7kVgKwtSURISTUwttS8m3rmoe/yuayX497UGm4PYuzbdumQ0Zqz04KSTcRbFZqP LLr+IVMxX3LV1xW7X7xfuGPNM9Elb9aWzzp83XL/zEgxrfD9h54Y7Kmuuzpjz8TYnN8WGy5/ YtX5bKzUdupVzu6n3Foc8pwHXrutPZOyR3Pt4YfrcpirjO9G/zr5LNU2pdDCKVSJpTgj0VCL uag4EQAlUb8VMwMAAA==
Archived-At: <>
Subject: Re: [OAUTH-WG] OAuth Working Group Meeting at IETF 99 21-Jul-17
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 21 Jul 2017 15:55:13 -0000

So even though I withdrew my suggestion of adding a parameter to device flow, that was only because my own direct reason was addressed, and I support adding it back in for all the reasons that Annabelle and Dick and John and others brought up in conversation. 

 — Justin

> On Jul 21, 2017, at 8:59 AM, Mike Jones <> wrote:
> OAuth Working Group Meeting at IETF 99 21-Jul-17
> 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 server
> 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 specs
> David Robin: There's an opportunity to send people straight to the final URL
> 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 Australia
>               If it's going to be an image, it should be a separate parameter
> 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 implementations
> 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 display
>               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 Considerations
> 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 add-on
> 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 publication
> 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 problem
>               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 runtime
> 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 mandatory
> 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 draft
> Brian:  I have ideas how to keep the intent but simplify
>               We would still describe how to detect and respond to attacks
> 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
>               draft-campbell-tokbind-ttrp
> 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 application
> 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 referenced
>               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 implementation
> 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 request
> 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
> _______________________________________________
> OAuth mailing list
> <>
> <>