Re: [OAUTH-WG] WGLC for OAuth 2.0 Device Flow for Browserless and Input Constrained Devices (Brian Campbell)

[William Denniss <[e-mail]>]

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 <[e-mail]> 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 <[e-mail]>
> 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, [e-mail] wrote:
> >>
> >> Send OAuth mailing list submissions to
> >>      [e-mail]
> >>
> >> 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
> >>      [e-mail]
> >>
> >> You can reach the person managing the list at
> >>      [e-mail]
> >>
> >> 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 <[e-mail]>
> >> To: Rifaat Shekh-Yusef <[e-mail]>
> >> Cc: oauth <[e-mail]>
> >> Subject: Re: [OAUTH-WG] WGLC for OAuth 2.0 Device Flow for Browserless
> >>      and Input Constrained Devices
> >> Message-ID:
> >>      <CA+k3eCRzTe2Xt_N-9mwsnc4WCdyWo3UTRe=UUnzcgidGpq
> [e-mail]>
> >> 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 <
> [e-mail]>
> >> 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
> >>> [e-mail]
> >>> 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 <[e-mail]>
> >> To: Brian Campbell <[e-mail]>
> >> Cc: Denis <[e-mail]>, "<[e-mail]>" <[e-mail]>
> >> Subject: Re: [OAUTH-WG] I-D Action:
> >>      draft-ietf-oauth-token-exchange-10.txt
> >> Message-ID: <[e-mail]>
> >> 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 <[e-mail]>
> 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 <[e-mail] <mailto:
> [e-mail]>> 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 <[e-mail]> <mailto:[e-mail]>
> on behalf of Brian Campbell <[e-mail]> <mailto:
> [e-mail]>
> >>>> 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 <[e-mail] <mailto:
> [e-mail]>> 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
> >>>>> [e-mail] <mailto:[e-mail]>
> >>>>> https://www.ietf.org/mailman/listinfo/oauth <
> https://www.ietf.org/mailman/listinfo/oauth>
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> OAuth mailing list
> >>>> [e-mail] <mailto:[e-mail]>
> >>>> 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
> >>> [e-mail] <mailto:[e-mail]>
> >>> 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
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/oauth
> >>
> >>
> >> ------------------------------
> >>
> >> End of OAuth Digest, Vol 110, Issue 8
> >> *************************************
> >
> > _______________________________________________
> > OAuth mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>