Hannes gave an OAuth WG status update
AMR Values spec sent to the IESG
Request by JWS spec sent to the IESG
Native apps specification
Recently updated to make it more readable
Hannes is working on a shepherd update
John Bradley said that some minor updates to the
Windows Universal Platform language are being done
It's nearly done. People are requested to provide
feedback.
People are using an SDK embodying this specification
that was published by the OpenID Connect working group
The spec is a BCP that we can revise as needed
Hannes suggested that a tutorial be done on how to
use the SDK at the next IETF
Hannes reviewed the published meeting agenda
OAuth Device Flow specification
Hannes described the specification
Issue #1 is about polling
The AS polls the device for the authorization code
Hannes asked whether there are other ways to deal
with this or whether polling is fine
Aaron Parecki said that polling is simple
William Denniss suggested also adding HTTP/2
long-poll as an option
Simon Moffatt said that the HTTP stack itself may be
too much
Torsten Lodderstedt said that the OpenID MODRNA WG
is working on similar specs
Hannes said that people appear to be happy enough
with polling
Torsten: MODRNA is using polling for back-channel
authentication
Also for user consent
There is not much implementation
experience yet
Torsten asked whether there is sufficient
implementation experience showing that polling works well enough
William Dennis: We run this at large scale. Every
YouTube TV app uses this. It works.
John Bradley: Roland Hedberg has use cases in which
identity proofing is interleaved and responses may be delayed
Polling works well if the replies come
soon
Leif Johansson: We could solve the long-response
time situations differently
Identity proofing is a longer-lived
use case
It's not reasonable to always assume
that authentication is quick
Hannes asked whether the long-latency authentication
use case might not be different than the device flow use case
Justin Richer: The long polling use case might just
need a different flow
Don't use the device flow in the
"three days later" use case
John Bradley: I'm OK with that
Hannes asked Leif to get together with Roland to
describe their use case
Hannes: From this discussion, it's clear that we go
ahead with what we have now
Issue #2 is about the user interface
AS provides user code and verification URI to the
user
User enters these on a separate device
What guidance can be given to improve the user
interaction and experience?
Dick Hardt asked what the question is and said that
Amazon makes a number of devices
Hannes got Dick to volunteer to write down some user
interface guidance
Issue #3 is about alternative contact mechanisms
In the current mechanism, the device shows the user
info that is entered in another place
A possible alternative is for the user to enter a
phone number into the device client, which initiates an SMS sending a user code
The user enters the user code
This could make the experience easier
and faster
Hannes: Should we document both methods or just the
current one?
Or should the additional mechanism be
documented in a different specification?
William Denniss: The protocol is the same so it's
fine to describe this in the same specification
John Bradley: There is an additional user hint
parameter
It is close enough that we should
probably describe this in the Device Flow document
Mike Jones: Asked whether there is deployment
experience with the second method
John Bradley: I have seen it in the wild
Phil Hunt: Asked whether sending people links
spontaneously to click on is training users in bad behaviors
Torsten Lodderstedt: Repeated Mike's question. Said
that at the minimum, the security considerations would be different.
Hannes will reach out asking for deployment
experience for the SMS method
If there isn't deployment experience,
we shouldn't include it
OAuth Authorization Server Metadata
Hannes started WGLC earlier this year
We got a bit stuck on this
This led to a new document on Resource Metadata
Hannes: In Berlin, there appeared to be consensus to proceed with
this work
Hannes would like to get feedback on where we are with the work
and how we should proceed
The AS Metadata document makes the AS configuration information
available online in a JSON structure
The Resource Metadata document does the same for protected
resources
Hannes: Should we publish one or both of these or should we do
additional security work?
Justin Richer: The AS Metadata document is very stable and
widely used. We should publish it.
Resource Metadata is a different beast. It's more
dynamic.
Different kinds of APIs need different kinds of
resource discovery
There are security considerations and subtle privacy
considerations with resource-first discovery
We shouldn't conflate the two
Tony Nadalin: I'm not sure the AS metadata document is accurate
enough to publish yet
We have a multi-tenant system and AS metadata about
only a single tenant causes problems
Tony is concerned that as we develop resource
metadata it might result in changes to the AS metadata
John Bradley: This document actually does deal with multi-tenant
situations
We are not precluding multi-tenant situations
I agree with Justin that resource metadata is more
complicated, since it relates closely to the protocol using OAuth
Being able to describe the characteristics of the AS
separately has value even without the resource metadata
Other specs can deal with the problems with resource
discovery
Trying to do it in metadata is the
wrong way to do it
William Denniss: I see the AS metadata as being valuable. It
improves security.
There is a fair bit of proven deployment experience
William doesn't have an immediate use for resource
metadata
Phil Hunt: His concern is that as we automate configuration we
make some things better both for the legitimate and for attackers
He is concerned that clients could be convinced to
use an attacker's resource proxy
Phil said that Mike Jones and he have been talking
and working on this
The resource metadata makes things better in
combination with the AS metadata
Phil thinks that the two specs should be combined
Phil is frustrated that there isn't a clear
understanding of the problems or the solutions
Phil said that Mike legitimately asked whether we
are solving a problem that people want to deploy solutions to
Phil asked whether there is willpower
to solve the problem
Hannes asked Phil whether he thought both should
move forward
Phil said that the most important thing is for
people to verify the relationships between the AS and resource
Phil and Hannes talked about the proof-of-possession
and token binding work being related to this
Hannes: People want to start with the simpler problem first and
then in a second phase, work on resource metadata
Phil: It's important for the client to understand whether it has
a valid set of endpoints and how the client knows that
We don't know whether to express this as metadata or
in some other way
Torsten: There is a need for automatic configuration to ASs
He's not sure whether there's such a need for
resources
The AS metadata is mature and proven. I propose
that we move it forward.
John Bradley: George Fletcher from AOL says that it's OK for the
client to specify what AS to use
It's OK if the AS doesn't have a pre-existing
relationship with the resource
It's fine as long as the access token is audienced
in a way that the token can't be replayed at a different resource
AS metadata is mature and ready for publication
Resource metadata is not mature and not ready for
publication
Brian Campbell and John did a draft allowing the
client to tell the AS where it plans to use the token
draft-campbell-oauth-resource-indicators
This enables the AS to audience
restrict the access token to the resource
Phil Hunt: We should keep the audience restriction idea on the
table
Phil asked about combining the documents in response to Hannes
formulating questions
Hannes said that that's just a document management
issue.
Hannes asked these questions:
1. Should we move forward with the AS metadata
document as a standalone document?
8 in favor
2. Should we adopt the resource metadata document?
2 in favor
3. Who thinks we should not adopt the resource
metadata document
4 against adoption
4. Should we work on a combined AS/RS document?
5 in favor
5. Should we stop work on metadata?
0 in favor
William Denniss: I disagree that they go together. We need the
AS metadata now. We don't need the other now.
They need not be linked
Hannes: Who is deploying the AS metadata specification?
The question got interrupted by clarification
questions
Tony Nadalin: Microsoft uses it but it doesn't meet our needs
because it doesn't support multi-tenancy
John Bradley: Microsoft publishes an AS metadata document per
tenant
Multi-tenancy is more a discovery issue than a
metadata issue
Leif Johansson: Salesforce does the same thing - publishing a
metadata document per tenant
Hannes: I am trying to determine deployment status
Phil: You have to have a bootstrap process to determine the AS
to use
William Dennis: Google has a real need that is solved by the AS
metadata spec
Torsten: It's just a URL and you obtain the metadata from it.
There's no magic. It works very well. It helps with mix-up.
Hannes asked:
6. Who has deployed or is planning to deploy AS
metadata?
9
7. Who has deployed or is planning to deploy
resource metadata?
1
Hannes:
My sense is that we should proceed with the AS
metadata
I see people using it already
I see people wanting it to progress it as a
standalone document
For resource metadata, I think additional
clarification is needed before we work on it as a working group
Kathleen Moriarty (Security Area Director): I agree with these
conclusions
OAuth 2.0 Token Binding
Brian Campbell gave a presentation on the status of Token Binding
for OAuth 2.0 and OpenID Connect
The current WG draft uses the referred token binding for token
binding access tokens
Brian talked about how using the referred token binding for
access tokens is conceptually the right thing
But that there may be practical problems with doing
this
Brian is concerned about the HTTPSTB text about
"explicitly signaling"
John Bradley (a TokBind chair): The current HTTPSTB
text is focused on the redirect case
There are also other use cases
supported by token binding
We may have to refactor the current
text
Dick Balfanz (HTTPSTB editor) said
that he was OK doing this
The privacy principle is that
unintended correlations not be created
In the OAuth case, it's the client who
should be making this decision
Brian asked Dirk if they could work on this text
together and Dirk agreed
Brian is concerned that using the referred token binding could be
cumbersome in some cases
For instance, clustered web server clients
HTTPSTB has a SHOULD for an eTLD+1 scoping requirement
This means that different access tokens would be
needed for resources not sharing an eTLD+1
This prevents token replay across resources not
sharing an eTLD+1
Torsten asked about the case in which resources
share keys
Torsten said that they use audienced
access tokens - different access tokens are used at different resources
John Bradley: Some of this may be platform-specific
In general, you're going to have to
indicate which referred token binding to use
If you have two different access
tokens, you should probably have different keys for them
Ben Kaduk: You're right that if you already use the
same access token across sites, they would need to share token binding keys
Hannes: I'm concerned that some deployment patterns
could lose some of the privacy properties of OAuth
Justin Richer: My skepticism of the use of Token
Binding for OAuth is that it's designed for browser cookies
OAuth access tokens aren't browser
cookies
Clients tend not to think in terms of
domains they're calling - they think in terms of APIs providing functionality
We are going to a world that's more
dynamic, which is a really hard nut to crack
Justin pointed out that Google uses
both google.com and googleapis.com
There are up to 5 TLS connections that
are involved in some OAuth flows
This is a very different
world than the browser case
It works well for ID Tokens in the
implicit flow and refresh tokens at the Token Endpoint
But it doesn't match
access token usage
Brian: Ideally the client developer isn't going to
have to know about these things
If you use the same key, it just works
Justin: What problem are we trying to solve?
Audience restriction or presentation restriction?
Brian: Both
Tony Nadalin: I am concerned about the browser
situation
John Bradley: We still have some questions about
JavaScript in the browser using fetch
eTLD+1 is still appropriate for that
use case
Brian: I am not proposing a change to token binding
William Dennis: I agree that access tokens are
somewhat tricky
The token binding gives us more
benefits than it adds in complexity
Brian: It makes sense to try to take advantage of
what token binding provides
Andrei Popov: The tokens should be scoped no
broader than the keys are scoped
The OAuth token binding specification
could live at the same level as the HTTPSTB specification
John Bradley: The data structures are defined in
the HTTPSTB specification
Things building on HTTPSTB makes more
sense than repeating most of HTTPSTB in other specifications
Torsten: Things can get tricky for access tokens.
Refresh tokens could get tricky as well.
John: The client being a cluster can make things
tricky
Torsten: Developers need to consider which access
tokens to use at which resources
Reusing things all over rightly makes
privacy people nervous
Is there any deployment experience?
Mike Jones: Microsoft internally has deployed
something with the same semantics but different syntax
Dick Hardt: Wants to enable refresh token to be
token bound without requiring access tokens be token bound
John: Nothing stops people from doing refresh
tokens now, because it doesn't actually have to be interoperable
William Denniss: We see a lot of value in
protecting the refresh token. Google is moving forward with that.
Dirk Balfanz: We are removing explicit mentions of
the key and always using the referred token binding
Brian: Where referred is possible, always use
referred. Otherwise, use explicit.
John: We tried to have only one way to do things
for each leg
You can provide two different token
bindings for different legs - one referred and one provided
This is being done in the next
document revision
Token binding for authorization codes is still TBD
Brian asked whether double binding (as described in
a doc by Dirk Balfanz before Berlin) is necessary
Brian presented a strawman for authorization code
token binding
It uses PKCE with a code_challenge
value that is a hash of the provided token binding ID
It uses a new code_challenge_method
value
The code_verifier is the provided
token binding ID
Binds the code to the channel between the browser
and the client
Brian proposed different methods for the native app
and browser client cases
Some of this was based on the proposal
that Dirk wrote prior to Berlin
The two methods are appropriate for
different kinds of clients
Torsten: Asked which is easier to implement
John: In OAuth, there is no signed response
In OpenID Connect, we can put it in
the ID Token, which is signed
The second method for browsers avoids
having to have a signed response
Dirk: The double binding isn't needed
Token Binding Metadata presented
The resource metadata now may be in question
Talked about phasing in Token Binding and detecting
downgrade attacks
It's more subtle than just "supports"
- it also includes all participants supporting the same cryptographic algorithms
The Boolean metadata values may not be granular
enough to actually express all the information needed
Support may be dependent upon platform features as
well
Next steps
Resolve conflict with wording in HTTPSTB
Add token binding for authorization codes
Flesh out or back off metadata and downgrade
detection logic
Hannes: We should work on getting implementation experience
OAuth 2.0 Token Exchange
Brian Campbell presented on the current Token Exchange status
Relatively minor changes were made last month
The want_composite request parameter was removed
It's ultimately up to the AS what to
issue
Added a short mention of PoP
Torsten: The current version is really light-weight
What I'm missing is a description of the
relationship between audience, resource, and scopes
Brian: I'm not sure how to do that
Torsten agreed to help Brian with wording
Tony Nadalin: We've been going through this doc with the
developers at Microsoft
Tony has asked them to describe their use cases and
what is needed for them
Their feedback is expected this week
The Microsoft developers are having problems mapping
the current document to their needs
John Bradley: Should we reconstitute the stand-alone resource
specification?
Hannes: That's a brilliant idea
William Denniss: I agree with Tony. I'd like to get a few
implementations done in the next year.
It's valuable to prove it out with some
implementations
Justin Richer: We will eventually implement this
I agree that more implementation experience will be
good for this
Developers are there and ready to try this out
Talked about the relationships between scopes,
resources, and audiences
Torsten: The use case of being able to indicate the resource is
very relevant for every client
John: We're seeing the development of general-purpose APIs
This was not initially imagined when OAuth was
developed
This means that we'll have scopes used across
contexts
This is part of OAuth growing up
I'm getting questions from customers about why Token
Exchange isn't done yet
Torsten: We didn't move the resource spec forward before because
resources without scopes don't make sense
There is implementation experience at Deutsche
Telekom with combining resources and scopes
John: Torsten is right that people do horrible things creating
structured scopes with key-value pairs that aren't interoperable
I suggest adopting the resource document as a
starting point to have these more general discussions
Hannes: We will discuss the resource indicator topic at our next
session on Wednesday
We should give it another try
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
