This suggestion was considered by the working group, I raised the proposal at IETF98, you can see the recording <https://youtu.be/kBEwdSKHLCA?t=49m54s> .
The WG rejected the inclusion of this construct in the device flow specification, but as Justin suggested, the door is open for a standalone document so that it could be useful for *all* OAuth clients, not just device flow ones. On Mon, Dec 11, 2017 at 12:41 PM, Justin Richer <[email protected]> wrote: > This could be useful but shouldn’t be done in a way that’s tied to the > device flow — any public client would suffer from the same fate. > > — Justin > > > On Dec 11, 2017, at 3:19 PM, Jaap Francke <[email protected]> > wrote: > > > > Hi all, > > > > I have previously made the following suggestion which still makes sense > to me. > > > > […]we were working with one of our customers to implement the device > flow as part of our IDaaS. > > One of the requirements was the ability to revoke tokens for one of the > devices at the Resource Server. > > > > In our use case, we used the terminolgy ‘pairing a device to the > enduser’s account’ to describe the process of authorising a device to > access the resource owner’s resources. > > The resource owner may want to ‘unpair’ a device from a list of paired > devices without having access to the device itself (anymore). Think about a > stolen/lost kind of situation. > > We are looking for ways to allow the user to unpair one of his devices > at the Authorisation Server. > > Since the Device Flow exchanges only the ‘generic’ client_id with the > Authorisation Server, there is no logical way at the Resource Server to > make a distinction between various devices (having the same client_id) that > may be paired to the same Resource Owner. > > > > My suggestion is the following > > - add an optional parameter to the device authorisation request (or > device access token request): 'device_identifier'. A device can use this to > make (for example) its serial-number known at the Resource Server. > > - add an optional parameter to the device access token response that > allows to communicate a name for the device as may have been given to it by > the resource owner while allowing the clients access (E). This parameter > could be something like ‘device_name’. The device may be able to display > this ‘device_name’ on its display. > > > > Please consider this as a suggested enhancement of the Device Flow > specifications. > > > > > > Kind regards, > > > > Jaap > >> On 11 Dec 2017, at 18:56, [email protected] wrote: > >> > >> Send OAuth mailing list submissions to > >> [email protected] > >> > >> To subscribe or unsubscribe via the World Wide Web, visit > >> https://www.ietf.org/mailman/listinfo/oauth > >> or, via email, send a message with subject or body 'help' to > >> [email protected] > >> > >> You can reach the person managing the list at > >> [email protected] > >> > >> When replying, please edit your Subject line so it is more specific > >> than "Re: Contents of OAuth digest..." > >> > >> > >> Today's Topics: > >> > >> 1. Re: WGLC for OAuth 2.0 Device Flow for Browserless and Input > >> Constrained Devices (Brian Campbell) > >> 2. Re: I-D Action: draft-ietf-oauth-token-exchange-10.txt > >> (Justin Richer) > >> > >> > >> ---------------------------------------------------------------------- > >> > >> Message: 1 > >> Date: Mon, 11 Dec 2017 09:46:09 -0700 > >> From: Brian Campbell <[email protected]> > >> To: Rifaat Shekh-Yusef <[email protected]> > >> Cc: oauth <[email protected]> > >> Subject: Re: [OAUTH-WG] WGLC for OAuth 2.0 Device Flow for Browserless > >> and Input Constrained Devices > >> Message-ID: > >> <CA+k3eCRzTe2Xt_N-9mwsnc4WCdyWo3UTRe=UUnzcgidGpq > [email protected]> > >> Content-Type: text/plain; charset="utf-8" > >> > >> I couldn't get the QR code to work... ;) > >> > >> On Mon, Nov 27, 2017 at 6:55 AM, Rifaat Shekh-Yusef < > [email protected]> > >> wrote: > >> > >>> All, > >>> > >>> As discussed in Singapore, we are starting a WGLC for the > >>> *draft-ietf-oauth-device-flow-07* document, starting today and ending > on > >>> December 11, 2018. > >>> https://datatracker.ietf.org/doc/draft-ietf-oauth-device-flow/ > >>> > >>> Please, review the document and provide feedback on the list. > >>> > >>> Regards, > >>> Rifaat & Hannes > >>> > >>> > >>> _______________________________________________ > >>> OAuth mailing list > >>> [email protected] > >>> https://www.ietf.org/mailman/listinfo/oauth > >>> > >>> > >> > >> -- > >> *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged > >> material for the sole use of the intended recipient(s). Any review, use, > >> distribution or disclosure by others is strictly prohibited. If you > have > >> received this communication in error, please notify the sender > immediately > >> by e-mail and delete the message and any file attachments from your > >> computer. Thank you.* > >> -------------- next part -------------- > >> An HTML attachment was scrubbed... > >> URL: <https://mailarchive.ietf.org/arch/browse/oauth/attachments/ > 20171211/119c614c/attachment.html> > >> > >> ------------------------------ > >> > >> Message: 2 > >> Date: Mon, 11 Dec 2017 12:56:21 -0500 > >> From: Justin Richer <[email protected]> > >> To: Brian Campbell <[email protected]> > >> Cc: Denis <[email protected]>, "<[email protected]>" <[email protected]> > >> Subject: Re: [OAUTH-WG] I-D Action: > >> draft-ietf-oauth-token-exchange-10.txt > >> Message-ID: <[email protected]> > >> Content-Type: text/plain; charset="utf-8" > >> > >> +1 to Brian > >> > >> -1 to the proposed text from Denis > >> > >> > >>> On Dec 8, 2017, at 8:48 PM, Brian Campbell <[email protected]> > wrote: > >>> > >>> The privacy matter is already mentioned. Despite your many messages to > this WG and others about the so called ABC attack, I do not believe it > warrants treatment in this document or others. And your continued proposals > to have it included in documents have not gotten support. > >>> > >>> On Fri, Dec 8, 2017 at 2:46 PM, Denis <[email protected] <mailto: > [email protected]>> wrote: > >>> RFC 3552 (Guidelines for Writing RFC Text on Security Considerations) > states: > >>> > >>> All RFCs are required by RFC 2223 to contain a Security > >>> Considerations section. The purpose of this is both to encourage > >>> document authors to consider security in their designs and to inform > >>> the reader of relevant security issues. This memo is intended to > >>> provide guidance to RFC authors in service of both ends. > >>> > >>> Section 5 (Writing Security Considerations Sections) of RFC 3552 > states: > >>> > >>> While it is not a requirement that any given protocol or system be > >>> immune to all forms of attack, it is still necessary for authors to > >>> consider as many forms as possible. Part of the purpose of the > >>> Security Considerations section is to explain what attacks are out of > >>> scope and what countermeasures can be applied to defend against them > >>> > >>> There should be a clear description of the kinds of threats on the > >>> described protocol or technology. > >>> > >>> It is important to mention the threat related to collusion attacks. A > different wording could be used, > >>> but the threat should be mentioned one way or another. > >>> > >>> RFC 6973 (Privacy Considerations for Internet Protocols) intends to > provide a similar set of guidelines > >>> for considering privacy in protocol design. > >>> > >>> It is important to mention a current threat related to privacy. A > different wording could be used, > >>> e.g. using the word "surveillance" as mentioned in 5.1.1 : > "Surveillance is the observation or monitoring > >>> of an individual?s communications or activities", but the threat > should be mentioned one way or another. > >>> > >>> Denis > >>> > >>>> I believe the text would detract from the document. > >>>> From: OAuth <[email protected]> <mailto:[email protected]> > on behalf of Brian Campbell <[email protected]> <mailto: > [email protected]> > >>>> Sent: Friday, December 8, 2017 3:47:32 PM > >>>> To: Denis > >>>> Cc: oauth > >>>> Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-token- > exchange-10.txt > >>>> > >>>> As an individual, I do not believe that the proposed text should be > incorporated into the draft. > >>>> > >>>> As one of the document editors, my responsibility is for the document > to be of reasonable quality and to reflect the rough consensus of this > Working Group. So I should ask the list more explicitly - are there other > WG remembers who are in favor of the proposed text here (the text would > have to be fixed up some too)? > >>>> > >>>> On Fri, Dec 1, 2017 at 11:12 AM, Denis <[email protected] <mailto: > [email protected]>> wrote: > >>>> Comments on draft-ietf-oauth-token-exchange-10 > >>>> > >>>> I propose the following rephrasing for sections 6 and 7: > >>>> > >>>> 6 . Security Considerations > >>>> > >>>> All of the normal security issues that are discussed in > [JWT],especially in relationship to comparing URIs > >>>> and dealing with unrecognized values, also apply here. In addition, > both delegation and impersonation introduce > >>>> unique security issues. Any time one user receives a token, the > potential for abuse is a concern, > >>>> since that user might be willing to collude with another user so that > other user could use the token. > >>>> > >>>> Techniques like the binding of an access token to a TLS channel > described elsewhere are ineffective since > >>>> the legitimate user would be able to perform all the cryptographic > computations that the other user would need > >>>> to demonstrate the ownership of the token. The use of the "scp" claim > is suggested to mitigate potential for > >>>> such abuse, as it restricts the contexts in which the token can be > exercised. If the issued access token scope > >>>> allows to unambiguously identify the user, then that user is likely > to be reluctant to collude with another user. > >>>> However, if the issued access token scope only indicates that the > user is over 18, then there is no risk > >>>> for the original user to be discovered and in such a context a > collusion may easily take place. > >>>> This document does not specify techniques to prevent such a collusion > to be successful. > >>>> > >>>> 7 . Privacy Considerations > >>>> > >>>> Tokens typically carry personal information and their usage in Token > Exchange may reveal details of the target services > >>>> being accessed. The resource and the audience parameters allow > authorization servers to know where the issued access token > >>>> will be used. This may be a privacy concern for some users. This > document does not specify techniques to prevent > >>>> authorization servers to know where the access tokens they issue will > be used. > >>>> > >>>> Denis > >>>>> A New Internet-Draft is available from the on-line Internet-Drafts > directories. > >>>>> This draft is a work item of the Web Authorization Protocol WG of > the IETF. > >>>>> > >>>>> Title : OAuth 2.0 Token Exchange > >>>>> Authors : Michael B. Jones > >>>>> Anthony Nadalin > >>>>> Brian Campbell > >>>>> John Bradley > >>>>> Chuck Mortimore > >>>>> Filename : draft-ietf-oauth-token-exchange-10.txt > >>>>> Pages : 32 > >>>>> Date : 2017-11-30 > >>>>> > >>>>> Abstract: > >>>>> This specification defines a protocol for an HTTP- and JSON- based > >>>>> Security Token Service (STS) by defining how to request and obtain > >>>>> security tokens from OAuth 2.0 authorization servers, including > >>>>> security tokens employing impersonation and delegation. > >>>>> > >>>>> > >>>>> The IETF datatracker status page for this draft is: > >>>>> https://datatracker.ietf.org/doc/draft-ietf-oauth-token-exchange/ < > https://datatracker.ietf.org/doc/draft-ietf-oauth-token-exchange/> > >>>>> > >>>>> There are also htmlized versions available at: > >>>>> https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-10 < > https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-10> > >>>>> https://datatracker.ietf.org/doc/html/draft-ietf-oauth- > token-exchange-10 <https://datatracker.ietf.org/doc/html/draft-ietf-oauth- > token-exchange-10> > >>>>> > >>>>> A diff from the previous version is available at: > >>>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-token-exchange-10 > <https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-token-exchange-10> > >>>>> > >>>>> > >>>>> Please note that it may take a couple of minutes from the time of > submission > >>>>> until the htmlized version and diff are available at tools.ietf.org > <http://tools.ietf.org/>. > >>>>> > >>>>> Internet-Drafts are also available by anonymous FTP at: > >>>>> ftp://ftp.ietf.org/internet-drafts/ <ftp://ftp.ietf.org/internet- > drafts/> > >>>>> > >>>>> _______________________________________________ > >>>>> OAuth mailing list > >>>>> [email protected] <mailto:[email protected]> > >>>>> https://www.ietf.org/mailman/listinfo/oauth < > https://www.ietf.org/mailman/listinfo/oauth> > >>>> > >>>> > >>>> _______________________________________________ > >>>> OAuth mailing list > >>>> [email protected] <mailto:[email protected]> > >>>> https://www.ietf.org/mailman/listinfo/oauth < > https://www.ietf.org/mailman/listinfo/oauth> > >>>> > >>>> > >>>> > >>>> CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited. > If you have received this communication in error, please notify the sender > immediately by e-mail and delete the message and any file attachments from > your computer. Thank you. > >>> > >>> > >>> > >>> CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited. > If you have received this communication in error, please notify the sender > immediately by e-mail and delete the message and any file attachments from > your computer. Thank you._______________________________________________ > >>> OAuth mailing list > >>> [email protected] <mailto:[email protected]> > >>> https://www.ietf.org/mailman/listinfo/oauth < > https://www.ietf.org/mailman/listinfo/oauth> > >> -------------- next part -------------- > >> An HTML attachment was scrubbed... > >> URL: <https://mailarchive.ietf.org/arch/browse/oauth/attachments/ > 20171211/dbd247f6/attachment.html> > >> > >> ------------------------------ > >> > >> Subject: Digest Footer > >> > >> _______________________________________________ > >> OAuth mailing list > >> [email protected] > >> https://www.ietf.org/mailman/listinfo/oauth > >> > >> > >> ------------------------------ > >> > >> End of OAuth Digest, Vol 110, Issue 8 > >> ************************************* > > > > _______________________________________________ > > OAuth mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth >
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
