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 <michael.jo...@microsoft.com> 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 > OAuth@ietf.org <mailto:OAuth@ietf.org> > https://www.ietf.org/mailman/listinfo/oauth > <https://www.ietf.org/mailman/listinfo/oauth>
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
