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=uunzcgidgpqm...@mail.gmail.com> >> 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
