Mike Jones
2016-11-14 06:50:39 UTC
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
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