Re: [OAUTH-WG] Location and dates for next OAuth Security Workshop

[Dick Hardt]

+1 to July / August. Nicer weather in the north then. =)

On Thu, Jul 25, 2019 at 11:56 AM Daniel Fett  wrote:

> Hi all,
>
> it seems like there is a rough consensus on having the next OAuth Security
> Workshop in Trondheim, Norway. We will therefore start with the planning.
>
> After checking various event calendars it seems like the following dates
> are suitable:
>
>
>* - May 7-9 - July 22-24 - August 3-5 *
>
>
>
> * First date is before EIC ‘20 which is May 12-15 in Munich/Germany. The
> latter two dates are before/after IETF 108 which is July 25-31,
> Madrid/Spain. Unless somebody raises objections because of conflicting
> identity/security events we will pick one of these dates in the next two
> weeks or so. -Daniel *
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Location and dates for next OAuth Security Workshop

[Dick Hardt]

Are we ready to pick a date?

On Thu, Jul 25, 2019 at 11:30 PM Dominick Baier 
wrote:

> August will conflict with holiday time for most Europeans…
>
> Just been to Trondheim last week - it was lovely weather.
>
> ———
> Dominick
>
> On 25. July 2019 at 22:14:28, Mike Jones (
> michael.jones=40microsoft@dmarc.ietf.org) wrote:
>
> I'm not aware of any conflicts for any of the three sets of dates.
>
> -- Mike
>
> -Original Message-
> From: OAuth  On Behalf Of Aaron Parecki
> Sent: Thursday, July 25, 2019 4:07 PM
> To: Dick Hardt 
> Cc: OAuth WG 
> Subject: Re: [OAUTH-WG] Location and dates for next OAuth Security
> Workshop
>
> We'll be so productive with only 4 hours of darkness every day!
>
> All of the dates work for me, but I would prefer the July dates since
> it'll be easier/cheaper to bundle the two trips into one. (Hopefully we
> could get the OAuth meeting dates early in the week at IETF then)
>
> On Thu, Jul 25, 2019 at 3:37 PM Dick Hardt  wrote:
> >
> > +1 to July / August. Nicer weather in the north then. =)
> >
> > On Thu, Jul 25, 2019 at 11:56 AM Daniel Fett 
> wrote:
> >>
> >> Hi all,
> >>
> >> it seems like there is a rough consensus on having the next OAuth
> Security Workshop in Trondheim, Norway. We will therefore start with the
> planning.
> >>
> >> After checking various event calendars it seems like the following
> dates are suitable:
> >>
> >> May 7-9
> >>
> >> July 22-24
> >>
> >> August 3-5
> >>
> >> First date is before EIC ‘20 which is May 12-15 in Munich/Germany. The
> latter two dates are before/after IETF 108 which is July 25-31,
> Madrid/Spain.
> >>
> >> Unless somebody raises objections because of conflicting
> identity/security events we will pick one of these dates in the next two
> weeks or so.
> >>
> >> -Daniel
> >>
> >> ___
> >> OAuth mailing list
> >> OAuth@ietf.org
> >> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww
> >> .ietf.org%2Fmailman%2Flistinfo%2Foauth&data=02%7C01%7CMichael.Jon
> >> es%40microsoft.com%7C4c0101bc1edc403d7b0e08d7113be77f%7C72f988bf86f14
> >> 1af91ab2d7cd011db47%7C1%7C0%7C636996821305207975&sdata=dAokWYxwGW
> >> SRXyrzs4V%2BWMXcMD482nhyARt28me4xbE%3D&reserved=0
> >
> > ___
> > OAuth mailing list
> > OAuth@ietf.org
> > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww..
> > ietf.org%2Fmailman%2Flistinfo%2Foauth&data=02%7C01%7CMichael.Jones
> > %40microsoft.com%7C4c0101bc1edc403d7b0e08d7113be77f%7C72f988bf86f141af
> > 91ab2d7cd011db47%7C1%7C0%7C636996821305207975&sdata=dAokWYxwGWSRXy
> > rzs4V%2BWMXcMD482nhyARt28me4xbE%3D&reserved=0
>
> ___
> OAuth mailing list
> OAuth@ietf.org
>
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth&data=02%7C01%7CMichael.Jones%40microsoft.com%7C4c0101bc1edc403d7b0e08d7113be77f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636996821305207975&sdata=dAokWYxwGWSRXyrzs4V%2BWMXcMD482nhyARt28me4xbE%3D&reserved=0
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Location and dates for next OAuth Security Workshop

[Dick Hardt]

Perhaps someone can teach Tony about emoticons to communicate his ironic
humor? =)

On Sat, Aug 10, 2019 at 1:52 AM Nat Sakimura  wrote:

> I think Tony was just joking as it was quite a hassle for both of us to
> get to Gjøvik for an ISO meeting.
>
> On Thu, Aug 8, 2019 at 9:50 PM Steinar Noem  wrote:
>
>> Hey Anthony. Gjøvik is part of NTNU, we are waiting for feedback from
>> them :)
>>
>> I think Trondheim is more accessible (travel time) and has more to offer..
>>
>> tor. 8. aug. 2019 kl. 14:42 skrev Anthony Nadalin > 40microsoft@dmarc.ietf.org>:
>>
>>> How about the University in Gjovik ?
>>>
>>> Get Outlook for Android <https://aka.ms/ghei36>
>>>
>>> --
>>> *From:* OAuth  on behalf of Daniel Fett <
>>> danielf+oa...@yes.com>
>>> *Sent:* Wednesday, August 7, 2019 11:47:51 PM
>>> *To:* Dick Hardt ; dba...@leastprivilege.com <
>>> dba...@leastprivilege.com>
>>> *Cc:* Mike Jones ; OAuth
>>> WG >
>>>
>>
>>> *Subject:* Re: [OAUTH-WG] Location and dates for next OAuth Security
>>> Workshop
>>>
>>> Not yet, we are talking to potential venues. It's vacation time in
>>> Norway right now, so that will take a week or two more.
>>>
>>> -Daniel
>>>
>>> Am 07.08.19 um 18:09 schrieb Dick Hardt:
>>>
>>> Are we ready to pick a date?
>>>
>>> On Thu, Jul 25, 2019 at 11:30 PM Dominick Baier <
>>> dba...@leastprivilege.com> wrote:
>>>
>>> August will conflict with holiday time for most Europeans…
>>>>
>>>> Just been to Trondheim last week - it was lovely weather.
>>>>
>>>> ———
>>>> Dominick
>>>>
>>>> On 25. July 2019 at 22:14:28, Mike Jones (
>>>> michael.jones=40microsoft@dmarc.ietf.org) wrote:
>>>>
>>> I'm not aware of any conflicts for any of the three sets of dates.
>>>>
>>>> -- Mike
>>>>
>>>> -Original Message-
>>>> From: OAuth  On Behalf Of Aaron Parecki
>>>> Sent: Thursday, July 25, 2019 4:07 PM
>>>> To: Dick Hardt 
>>>> Cc: OAuth WG 
>>>> Subject: Re: [OAUTH-WG] Location and dates for next OAuth Security
>>>> Workshop
>>>>
>>>> We'll be so productive with only 4 hours of darkness every day!
>>>>
>>>> All of the dates work for me, but I would prefer the July dates since
>>>> it'll be easier/cheaper to bundle the two trips into one. (Hopefully we
>>>> could get the OAuth meeting dates early in the week at IETF then)
>>>>
>>>> On Thu, Jul 25, 2019 at 3:37 PM Dick Hardt 
>>>> wrote:
>>>> >
>>>> > +1 to July / August. Nicer weather in the north then. =)
>>>> >
>>>> > On Thu, Jul 25, 2019 at 11:56 AM Daniel Fett 
>>>> wrote:
>>>> >>
>>>> >> Hi all,
>>>> >>
>>>> >> it seems like there is a rough consensus on having the next OAuth
>>>> Security Workshop in Trondheim, Norway. We will therefore start with the
>>>> planning.
>>>> >>
>>>> >> After checking various event calendars it seems like the following
>>>> dates are suitable:
>>>> >>
>>>> >> May 7-9
>>>> >>
>>>> >> July 22-24
>>>> >>
>>>> >> August 3-5
>>>> >>
>>>> >> First date is before EIC ‘20 which is May 12-15 in Munich/Germany.
>>>> The latter two dates are before/after IETF 108 which is July 25-31,
>>>> Madrid/Spain.
>>>> >>
>>>>
>>>> >> Unless somebody raises objections because of conflicting
>>>> identity/security events we will pick one of these dates in the next two
>>>> weeks or so
>>>>
>>>> >>
>>>> >> -Daniel
>>>> >>
>>>> >> ___
>>>> >> OAuth mailing list
>>>> >> OAuth@ietf.org
>>>> >>
>>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww
>>>> <https://www>
>>>> >> .ietf.org
>>>> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fietf.org&data=02%7C01%7Ctonynad%40microsoft.

Re: [OAUTH-WG] Info on how to implement a server

[Dick Hardt]

What is the goal?

On Sun, Aug 18, 2019 at 12:41 PM Salz, Rich  wrote:

> Thanks for the links, folks.  I’m aware, and sorry for my sloppy
> terminology.
>
>
>
> Imagine a service where anyone with a valid identity is authorized. There
> are many of these on the net. Collapsing authentication to authorization
> (“everyone authenticated is authorized”) seems not unreasonable.
>
>
>
> But I don’t want to get distracted from my main goal.  Thanks.
>
>
>
> *From: *Hans Zandbelt 
> *Date: *Saturday, August 17, 2019 at 2:34 PM
> *To: *John Bradley 
> *Cc: *"oauth@ietf.org" 
> *Subject: *Re: [OAUTH-WG] Info on how to implement a server
>
>
>
> indeed OAuth != identity see https://oauth.net/articles/authentication/
> 
>
>
>
> Hans.
>
>
>
> On Sat, Aug 17, 2019 at 8:31 PM John Bradley  wrote:
>
> The openID Connect kind of OAuth server.
>
> OAuth on its own is not designed to be secure for identity federation.
>
> John B.
>
> On 8/17/2019 1:23 PM, Salz, Rich wrote:
>
> What’s the WG consensus (heh) on the best guide to adding OAUTH support to
> an existing server so that it can act as an identity provider?  Which
> version of oauth is most widely deployed by relying parties these days?
>
>
>
> I want to add OAUTH support to the IETF datatracker.
>
>
>
> Thanks for any pointers.  Replies to me will be summarized for the list.
>
>
>
> /r$
>
>
>
>
>
> ___
>
> OAuth mailing list
>
> OAuth@ietf.org
>
> https://www.ietf.org/mailman/listinfo/oauth 
> 
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
> 
>
>
>
>
> --
>
> hans.zandb...@zmartzone.eu
>
> ZmartZone IAM - www.zmartzone.eu
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Info on how to implement a server

[Dick Hardt]

That sounds like a means to an end.

Do you want to enable applications to call datatracker APIs?

On Sun, Aug 18, 2019 at 2:05 PM Salz, Rich  wrote:

> As I said at the start of the thread: I want to add OAUTH support to the
> datatracker.
>
>
>
> *From: *Dick Hardt 
> *Date: *Sunday, August 18, 2019 at 4:47 PM
> *To: *Rich Salz 
> *Cc: *Hans Zandbelt , John Bradley <
> ve7...@ve7jtb.com>, "oauth@ietf.org" 
> *Subject: *Re: [OAUTH-WG] Info on how to implement a server
>
>
>
> What is the goal?
>
>
>
> On Sun, Aug 18, 2019 at 12:41 PM Salz, Rich  wrote:
>
> Thanks for the links, folks.  I’m aware, and sorry for my sloppy
> terminology.
>
>
>
> Imagine a service where anyone with a valid identity is authorized. There
> are many of these on the net. Collapsing authentication to authorization
> (“everyone authenticated is authorized”) seems not unreasonable.
>
>
>
> But I don’t want to get distracted from my main goal.  Thanks.
>
>
>
> *From: *Hans Zandbelt 
> *Date: *Saturday, August 17, 2019 at 2:34 PM
> *To: *John Bradley 
> *Cc: *"oauth@ietf.org" 
> *Subject: *Re: [OAUTH-WG] Info on how to implement a server
>
>
>
> indeed OAuth != identity see https://oauth.net/articles/authentication/
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__oauth.net_articles_authentication_&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=QNNK_MY9rFkxOH8kTY5Lb9XzaocnzqHfE2Qy1s1rKIQ&s=S3hNRZN-F73VNr2ls-yKN4bJPSuH4w92SmFc1PAvi4M&e=>
>
>
>
> Hans.
>
>
>
> On Sat, Aug 17, 2019 at 8:31 PM John Bradley  wrote:
>
> The openID Connect kind of OAuth server.
>
> OAuth on its own is not designed to be secure for identity federation.
>
> John B.
>
> On 8/17/2019 1:23 PM, Salz, Rich wrote:
>
> What’s the WG consensus (heh) on the best guide to adding OAUTH support to
> an existing server so that it can act as an identity provider?  Which
> version of oauth is most widely deployed by relying parties these days?
>
>
>
> I want to add OAUTH support to the IETF datatracker.
>
>
>
> Thanks for any pointers.  Replies to me will be summarized for the list.
>
>
>
> /r$
>
>
>
>
>
> ___
>
> OAuth mailing list
>
> OAuth@ietf.org
>
> https://www.ietf.org/mailman/listinfo/oauth 
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_oauth&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=QNNK_MY9rFkxOH8kTY5Lb9XzaocnzqHfE2Qy1s1rKIQ&s=mYG4MvYj3IpSidDiigZr4NtmXiZ4uzpxrFAGd2WtoFM&e=>
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_oauth&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=QNNK_MY9rFkxOH8kTY5Lb9XzaocnzqHfE2Qy1s1rKIQ&s=mYG4MvYj3IpSidDiigZr4NtmXiZ4uzpxrFAGd2WtoFM&e=>
>
>
>
>
> --
>
> hans.zandb...@zmartzone.eu
>
> ZmartZone IAM - www.zmartzone.eu
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.zmartzone.eu&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=QNNK_MY9rFkxOH8kTY5Lb9XzaocnzqHfE2Qy1s1rKIQ&s=rdGZncYUqvlwcXI7_GGrc5Niii46pDWHdpVklsb0Ijg&e=>
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_oauth&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=Un8tdGinIVpAqStU4GTgZWwQjRL7tMLUWFLfG5Hciv8&s=rL3JkU3byB6rcZdglzIdfzLMChWwgTRubGUYwiDl_k8&e=>
>
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Info on how to implement a server

[Dick Hardt]

On Sun, Aug 18, 2019 at 2:29 PM Salz, Rich  wrote:

> Not to be pedantic, but adding OAuth support is a mechanism in support
> of a goal. What's the end goal?
>
> * Letting third party apps use the datatracker API?
> * Letting people sign in to other apps with a datatracker account?
>

> The latter.
>

Then you want OpenID Connect



>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Question regarding RFC 7592

[Dick Hardt]

Curious why the client management API uses bearer tokens rather than JWTs
per RFC 7523 for the client to authenticate. The client management API
seems more similar to a token endpoint than a resource.
ᐧ

On Fri, Sep 13, 2019 at 12:08 PM Justin Richer  wrote:

> Travis has this correct — the “registration access token” is passed to the
> client for the express purpose of accessing the client management API, and
> is not the same as, or entangled with, any access tokens that the client
> requests through the OAuth process after the registration has occurred. The
> reasons for this separation are many, but at the core it comes down to the
> client always acting on its own behalf when it does registration, and
> acting on behalf of some other party (usually a user) when it’s doing
> OAuth. Additionally, registration management is a function of the AS,
> whereas the protected APIs are a function of the RS — note this is a
> logical separation and there’s nothing stopping AS and RS functions from
> being deployed in any number of patterns.
>
> A few common questions we got asked when writing this functionality into
> the spec:
>
> *Why use an access token at all*? Because it’s a credential for a
> specific API issued by the AS and handed to the client in a programmatic
> manner. This is exactly what OAuth tokens were made for.
>
> *Why not use the client’s credentials*? Because not all clients are set
> up to have credentials, plus we’d be spreading the requirement to support
> different kinds of client credentials to another endpoint.
>
> *Why not issue an authorization code*? Because then the client would need
> to make yet another round trip, and not all clients are
> authorization-code-grant clients to begin with.
>
> *Why not make a new grant type*? Because then the client would need to
> make yet another round trip, and we’d have to invent a whole new grant type
> with a new temporary credential when we could just use that temporary
> credential directly instead.
>
> — Justin
>
> On Sep 13, 2019, at 8:23 AM, Robache Hervé  wrote:
>
> Thanks Travis
>
> I understand that, once the client has retrieved its [client_id] through
> RFC7591 initial registration, it is then able to ask for an access token
> that will be used for accessing the RFC7592 entry-points. Am I right?
>
> Best regards
>
> Hervé
>
> *De :* Travis Spencer [mailto:travis.spen...@curity.io
> ]
> *Envoyé :* ven. 13 13:30
> *À :* Robache Hervé
> *Cc :* oauth@ietf.org
> *Objet :* Re: [OAUTH-WG] Question regarding RFC 7592
>
> No. The initial access token is issued by the AS when registration is
> protected (appendix 1.2 in RFC 7591). As stated in section 1.2, the method
> and means by which this is obtained can vary. The registration access token
> in RFC 7592 is used to protect the registration management API and allow
> updates to the client after it is registered. You might have one (the
> registration access token) but not the other (initial access token) when
> open registration is allowed (appendix 1.1 in RFC 7591).
>
> HTH!
>
> On Fri, Sep 13, 2019 at 7:37 AM Robache Hervé 
> wrote:
>
> Hi
>
> RFC 7592 introduces a « Registration Access Token ». Are this token and
> the way to get it similar to what is specified as “Initial Access Token” in
> RFC 7591/Appendix A ?
>
> If so, can the Open Dynamic Client Registration (RFC7591/A.1.1) be
> extrapolated to RFC7592 as the same way?
>
> Thanks in advance for your clarification.
>
> Hervé ROBACHE
> Direction Marketing et Développement
>
> LIGNE DIRECTE
> T. +33(0)1 55 23 55 45
> herve.roba...@stet.eu
>
> 
>
>
>
> 
>
> STET (SIEGE SOCIAL)
> 100, Esplanade du Général de Gaulle
> Cœur Défense – Tour B
> 92932 La Défense cedex
>
> www.stet.eu
>
>
>
> Ce message et toutes les pièces jointes sont établis à l'intention
> exclusive de ses destinataires et sont confidentiels.
> Si vous recevez ce message par erreur ou s'il ne vous est pas destiné,
> merci de le détruire ainsi que toute copie de votre système et d'en avertir
> immédiatement l'expéditeur.
> Toute lecture non autorisée, toute utilisation de ce message qui n'est pas
> conforme à sa destination, toute diffusion ou toute publication, totale ou
> partielle, est interdite.
> L'Internet ne permettant pas d'assurer l'intégrité de ce message
> électronique susceptible d'altération, STET décline toute responsabilité au
> titre de ce message dans l'hypothèse où il aurait été modifié, déformé ou
> falsifié.
> N'imprimez ce message que si nécessaire, pensez à l'environnement.
>
> This message and any attachments is intended solely for the intended
> addressees and is confidential.
> If you receive this message in error, or are not the intended
> recipient(s), please delete it and any copies from your systems and
> immediately notify the sender.
> Any unauthorized view, use that does not comply with its purpose,
> dissemination or disclosure, either whole or partial, is prohibited.
> Since the internet cannot guarantee the integrity of this message which
>

Re: [OAUTH-WG] Question regarding RFC 7592

[Dick Hardt]

The registration supports the client having a jwks, so if the client
provides jwks, then using them to sign an authentication request seems
easier than trying to manage an access token.

The token endpoint is an API as well. We would agree that it is not a
resource, but a management API. Similarly, I see the client's management of
its registration to not be a resource operation, but a management API.
ᐧ

On Mon, Sep 16, 2019 at 7:36 PM Justin Richer  wrote:

> I don’t see a reason to use an assertion here. JWT authentication would
> require at least a secret if not a key of some type for authentication for
> all clients, and it was determined that dynamic registration shouldn’t
> require the clients (even public clients) to support things they weren’t
> already capable of doing. Besides, the management endpoint isn’t a token
> endpoint (though I’m curious to hear why you’d say that) — it’s an API you
> can call to manage a client’s registration data over time. Sounds like an
> RS, if you ask me.
>
> — Justin
>
> On Sep 15, 2019, at 1:05 AM, Dick Hardt  wrote:
>
> Curious why the client management API uses bearer tokens rather than JWTs
> per RFC 7523 for the client to authenticate. The client management API
> seems more similar to a token endpoint than a resource.
> ᐧ
>
> On Fri, Sep 13, 2019 at 12:08 PM Justin Richer  wrote:
>
>> Travis has this correct — the “registration access token” is passed to
>> the client for the express purpose of accessing the client management API,
>> and is not the same as, or entangled with, any access tokens that the
>> client requests through the OAuth process after the registration has
>> occurred. The reasons for this separation are many, but at the core it
>> comes down to the client always acting on its own behalf when it does
>> registration, and acting on behalf of some other party (usually a user)
>> when it’s doing OAuth. Additionally, registration management is a function
>> of the AS, whereas the protected APIs are a function of the RS — note this
>> is a logical separation and there’s nothing stopping AS and RS functions
>> from being deployed in any number of patterns.
>>
>> A few common questions we got asked when writing this functionality into
>> the spec:
>>
>> *Why use an access token at all*? Because it’s a credential for a
>> specific API issued by the AS and handed to the client in a programmatic
>> manner. This is exactly what OAuth tokens were made for.
>>
>> *Why not use the client’s credentials*? Because not all clients are set
>> up to have credentials, plus we’d be spreading the requirement to support
>> different kinds of client credentials to another endpoint.
>>
>> *Why not issue an authorization code*? Because then the client would
>> need to make yet another round trip, and not all clients are
>> authorization-code-grant clients to begin with.
>>
>> *Why not make a new grant type*? Because then the client would need to
>> make yet another round trip, and we’d have to invent a whole new grant type
>> with a new temporary credential when we could just use that temporary
>> credential directly instead.
>>
>> — Justin
>>
>> On Sep 13, 2019, at 8:23 AM, Robache Hervé  wrote:
>>
>> Thanks Travis
>>
>> I understand that, once the client has retrieved its [client_id] through
>> RFC7591 initial registration, it is then able to ask for an access token
>> that will be used for accessing the RFC7592 entry-points. Am I right?
>>
>> Best regards
>>
>> Hervé
>>
>> *De :* Travis Spencer [mailto:travis.spen...@curity.io
>> ]
>> *Envoyé :* ven. 13 13:30
>> *À :* Robache Hervé
>> *Cc :* oauth@ietf.org
>> *Objet :* Re: [OAUTH-WG] Question regarding RFC 7592
>>
>> No. The initial access token is issued by the AS when registration is
>> protected (appendix 1.2 in RFC 7591). As stated in section 1.2, the method
>> and means by which this is obtained can vary. The registration access token
>> in RFC 7592 is used to protect the registration management API and allow
>> updates to the client after it is registered. You might have one (the
>> registration access token) but not the other (initial access token) when
>> open registration is allowed (appendix 1.1 in RFC 7591).
>>
>> HTH!
>>
>> On Fri, Sep 13, 2019 at 7:37 AM Robache Hervé 
>> wrote:
>>
>> Hi
>>
>> RFC 7592 introduces a « Registration Access Token ». Are this token and
>> the way to get it similar to what is specified as “Initial Access Token” in
>> RFC 7591/Appendix A ?
>>
>> If so, can the Open Dynamic Client Regi

Re: [OAUTH-WG] Question regarding RFC 7592

[Dick Hardt]

I think of cloud infrastructure having control plane, and data plane.
Control plane APIs are for managing the things that use the data plane. The
data plane is the resource. Not trying to change your mind, just sharing my
thinking.

On related efforts, in FastFed, we are looking at using a JWT to access
other control plane APIs.

I agree on first take, that storing an access token is easier than
working with a key pair. I should have more context, which is managing the
credential life cycle. What happens if the access token is lost or
compromised? Does the app need to be completely re-registered? With a
jwks-uri, the client can rotate their keys and continue to make API calls
if the private key is lost or compromised.

ᐧ

On Tue, Sep 17, 2019 at 8:10 AM Justin Richer  wrote:

> I think this is where we disagree about the nature of “resource”, as I
> would classify a management API as a resource. Specifically, the client’s
> own records at the AS.
>
> The “IF” in your statement is a big if, and one that is uncommon even
> today. Also, I want to note that if the client can’t "manage an access
> token” very well, then it’s going to have a very hard time being an OAuth
> client once it’s done registering. In other words, the goal was to take a
> piece of universal functionality that all OAuth clients would be guaranteed
> to have.
>
> I’ll agree that it’s a bit weird having an access token issued as part of
> a response, but the alternative was to invent a new flow to force a client
> to go through another round trip to the token endpoint to get its
> management token. If you’re already directly giving the client a temporary
> credential that it can use at the AS, then just give the client the final
> token to do the job directly instead. At least, that was the thinking, and
> I still agree with that line of thought today even with its quirks.
>
> — Justin
>
> On Sep 17, 2019, at 12:40 AM, Dick Hardt  wrote:
>
> The registration supports the client having a jwks, so if the client
> provides jwks, then using them to sign an authentication request seems
> easier than trying to manage an access token.
>
> The token endpoint is an API as well. We would agree that it is not a
> resource, but a management API. Similarly, I see the client's management of
> its registration to not be a resource operation, but a management API.
> ᐧ
>
> On Mon, Sep 16, 2019 at 7:36 PM Justin Richer  wrote:
>
>> I don’t see a reason to use an assertion here. JWT authentication would
>> require at least a secret if not a key of some type for authentication for
>> all clients, and it was determined that dynamic registration shouldn’t
>> require the clients (even public clients) to support things they weren’t
>> already capable of doing. Besides, the management endpoint isn’t a token
>> endpoint (though I’m curious to hear why you’d say that) — it’s an API you
>> can call to manage a client’s registration data over time. Sounds like an
>> RS, if you ask me.
>>
>> — Justin
>>
>> On Sep 15, 2019, at 1:05 AM, Dick Hardt  wrote:
>>
>> Curious why the client management API uses bearer tokens rather than JWTs
>> per RFC 7523 for the client to authenticate. The client management API
>> seems more similar to a token endpoint than a resource.
>> ᐧ
>>
>> On Fri, Sep 13, 2019 at 12:08 PM Justin Richer  wrote:
>>
>>> Travis has this correct — the “registration access token” is passed to
>>> the client for the express purpose of accessing the client management API,
>>> and is not the same as, or entangled with, any access tokens that the
>>> client requests through the OAuth process after the registration has
>>> occurred. The reasons for this separation are many, but at the core it
>>> comes down to the client always acting on its own behalf when it does
>>> registration, and acting on behalf of some other party (usually a user)
>>> when it’s doing OAuth. Additionally, registration management is a function
>>> of the AS, whereas the protected APIs are a function of the RS — note this
>>> is a logical separation and there’s nothing stopping AS and RS functions
>>> from being deployed in any number of patterns.
>>>
>>> A few common questions we got asked when writing this functionality into
>>> the spec:
>>>
>>> *Why use an access token at all*? Because it’s a credential for a
>>> specific API issued by the AS and handed to the client in a programmatic
>>> manner. This is exactly what OAuth tokens were made for.
>>>
>>> *Why not use the client’s credentials*? Because not all clients are set
>>> up to have credentials, plus we’d be spreadin

Re: [OAUTH-WG] WGLC on draft-ietf-oauth-reciprocal-04

[Dick Hardt]

Brian / George: thanks for the detailed critique of the draft -- much
appreciated.

Given all the feedback, it is clear the draft needs more work before
submitting to the IESG.

Unfortunately, it will be a few weeks before I have time to review and
respond to your comments.

ᐧ



On Fri, Sep 6, 2019 at 11:42 AM Rifaat Shekh-Yusef 
wrote:

> All,
>
> We are starting a WGLC on the Reciprocal OAuth document:
> https://datatracker.ietf.org/doc/draft-ietf-oauth-reciprocal/
>
> Please, review the document and provide feedback on any issues you see
> with the document.
>
> The WGLC will end 20-September-2019.
>
> Regards,
>  Rifaat and Hannes
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] New Version Notification for draft-lodderstedt-oauth-par-00.txt

[Dick Hardt]

If I understand the proposal correctly, the request URI is opaque to the
client. Correct?

If so, why not just treat it as an opaque string?

If I were implementing the protocol, I would have the blob be a signed
token so that I could verify the integrity before making a database call.
It much easier to throw compute at a DDOS attack to verify a signature,
than DB capacity.

ᐧ

On Thu, Sep 26, 2019 at 2:24 PM Justin Richer  wrote:

> Yes, the request object is JWT-based, but the request URI is not. In other
> words, you can post a JWT but what you get back is a URI, not the JWT
> itself.  The request URI was always meant to be a reference, and originally
> it was explicitly a reference to a signed request object.
>
> — Justin
>
> On Sep 26, 2019, at 10:03 AM, Aaron Parecki  wrote:
>
> The URI is intended to be a reference not a value. If the client could
> send a JWT it would just send a request object instead of a request URI in
> the first place. So the intent is that it’s random, and maybe we should
> just say that explicitly.
>
>
> I thought this language was explicitly to allow the use of structured
> values for the request_uri? From the introduction:
>
> but it also allows clients requiring an even
> higher security level, especially cryptographically confirmed non-
> repudiation, to explicitly adopt JWT-based request objects.
>
>
> 
> Aaron Parecki
> aaronparecki.com
>
> On Thu, Sep 26, 2019 at 6:49 PM Justin Richer  wrote:
>
>
> Aaron, some comments inline.
>
> — Justin
>
> On Sep 26, 2019, at 8:30 AM, Aaron Parecki  wrote:
>
> Hi Torsten,
>
> I'm very glad to see this draft, I think it's definitely needed in
> this space. Here are some of my thoughts on the draft.
>
> "request_uri": "urn:example:bwc4JK-ESC0w8acc191e-Y1LTC2"
>
>
> Is it acceptable for the AS to return just an opaque string, rather
> than something prefixed with "uri:*"? I don't think anyone would be
> confused about copypasting the exact string from the "request_uri"
> response into the "request_uri" parameter even if it didn't start with
> "urn:". If, for whatever reason, it is required that this value is
> actually a URI, is there some expected namespace to use other than
> "example"? I worry that if all the examples in the spec are just
> "urn:example:bwc4JK-ESC0w8acc191e-Y1LTC2" then developers will end up
> using the text "example" because they don't understand why it's there,
> and then it serves no purpose really.’
>
>
> This field must be a URI, as per JAR:
>
>   request_uri  The absolute URI as defined by RFC3986 [RFC3986] that
>  points to the Request Object (Section 2.1) that holds
>  authorization request parameters stated in section 4 of OAuth 2.0
>  [RFC6749].
>
> Somewhat awkwardly, the JAR spec currently states that the AS has to do an
> HTTP GET on the request URI, so that will need to be fixed in JAR before it
> goes forward. I don’t think that was always the case though, and I’m not
> sure how that changed.
>
> As for the namespace, “example” is ok for an example URN. The problem with
> URNs is that nobody really understands how to do domain-safe fully
> compliant URNs. So perhaps we should instead use “urn:fdc:example..com:….”
> Instead (as per https://tools.ietf.org/html/rfc4198).
>
>
> The pushed authorization request endpoint shall be a RESTful API
>
>
> I would drop the term RESTful and just say "HTTP API", as this
> description is arguably RESTful at best.
>
> Depending on client type and authentication method, the request might
> also include the "client_id" parameter.
>
>
> I assume this is hinting at the difference between public clients
> sending only the "client_id" parameter and confidential clients
> sending only the HTTP Basic Authorization header which includes both
> the client ID and secret? It would probably be helpful to call out
> these two common examples if I am understanding this correctly,
> otherwise it seems pretty vague.
>
>
> Not quite, those differences are for the token endpoint, and this is
> capturing things from the authorization endpoint. I don’t quite understand
> the differentiation listed here either, though.
>
>
> The "request_uri" value MUST be generated using a cryptographically
> strong pseudorandom algorithm
>
>
> I assume this includes the use of a random number inside of a JWT, in
> case the AS wants to use JWTs as the "request_uri" parameter"? If so,
> it's probably worth spelling that out as it kind of reads like it has
> to be literally a random string at first glance.
>
>
> The URI is intended to be a reference not a value. If the client could
> send a JWT it would just send a request object instead of a request URI in
> the first place. So the intent is that it’s random, and maybe we should
> just say that explicitly.
>
>
> That's all for now, thanks!
>
> 
> Aaron Parecki
> aaronparecki.com
> @aaronpk
>
> On Sat, Sep 21, 2019 at 1:02 PM Torsten Lodderstedt
>  wrote:
>
>
> Hi all,
>
> I just published a new draft that Brian Campbell, Dave Tonge, 

Re: [OAUTH-WG] New Version Notification for draft-lodderstedt-oauth-par-00.txt

[Dick Hardt]

I can understand the request URI being a URI that the client is providing
the AS, but why would the client's request URI be at the AS?

As Justin has explained it in the past, the AS is returning a handle to the
transaction. The only party that understands that handle as far as I know
is the AS. It is meaningless to the client. Perhaps I am missing something
else?
ᐧ

On Mon, Sep 30, 2019 at 2:53 AM Dave Tonge 
wrote:

> So although for this spec, request_uri is just an opaque string, it is
> defined more generally in
> https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-19#section-2.2 as an:
>
> * Absolute URI from which the Request Object (Section 2.1) can be obtained*
>
>
> And in section 5.2 as:
>
>
>> *The "request_uri" value MUST be either URN as defined in*
>> *   RFC8141 [RFC8141] or "https" URI, as defined in 2.7.2 of RFC7230*
>> *   [RFC7230] .  The "request_uri" value MUST be reachable by the**
>>  Authorization Server.*
>
>
> So this is why in the spec we have example of a URN and we have an ongoing
> discussion as to whether we should have a standard urn namespace that we
> recommend implementers use.
>
> In the interest of keeping the specs in sync I think it makes sense to
> keep it a URN for this spec, but with more of an explanation as to why?
>
> Dave
>
> On Fri, 27 Sep 2019 at 19:22, Dick Hardt  wrote:
>
>> If I understand the proposal correctly, the request URI is opaque to the
>> client. Correct?
>>
>> If so, why not just treat it as an opaque string?
>>
>> If I were implementing the protocol, I would have the blob be a signed
>> token so that I could verify the integrity before making a database call..
>> It much easier to throw compute at a DDOS attack to verify a signature,
>> than DB capacity.
>>
>> ᐧ
>>
>> On Thu, Sep 26, 2019 at 2:24 PM Justin Richer  wrote:
>>
>>> Yes, the request object is JWT-based, but the request URI is not. In
>>> other words, you can post a JWT but what you get back is a URI, not the JWT
>>> itself.  The request URI was always meant to be a reference, and originally
>>> it was explicitly a reference to a signed request object.
>>>
>>> — Justin
>>>
>>> On Sep 26, 2019, at 10:03 AM, Aaron Parecki  wrote:
>>>
>>> The URI is intended to be a reference not a value.. If the client could
>>> send a JWT it would just send a request object instead of a request URI in
>>> the first place. So the intent is that it’s random, and maybe we should
>>> just say that explicitly.
>>>
>>>
>>> I thought this language was explicitly to allow the use of structured
>>> values for the request_uri? From the introduction:
>>>
>>> but it also allows clients requiring an even
>>> higher security level, especially cryptographically confirmed non-
>>> repudiation, to explicitly adopt JWT-based request objects.
>>>
>>>
>>> 
>>> Aaron Parecki
>>> aaronparecki.com
>>>
>>> On Thu, Sep 26, 2019 at 6:49 PM Justin Richer  wrote:
>>>
>>>
>>> Aaron, some comments inline.
>>>
>>> — Justin
>>>
>>> On Sep 26, 2019, at 8:30 AM, Aaron Parecki  wrote:
>>>
>>> Hi Torsten,
>>>
>>> I'm very glad to see this draft, I think it's definitely needed in
>>> this space. Here are some of my thoughts on the draft.
>>>
>>> "request_uri": "urn:example:bwc4JK-ESC0w8acc191e-Y1LTC2"
>>>
>>>
>>> Is it acceptable for the AS to return just an opaque string, rather
>>> than something prefixed with "uri:*"? I don't think anyone would be
>>> confused about copypasting the exact string from the "request_uri"
>>> response into the "request_uri" parameter even if it didn't start with
>>> "urn:". If, for whatever reason, it is required that this value is
>>> actually a URI, is there some expected namespace to use other than
>>> "example"? I worry that if all the examples in the spec are just
>>> "urn:example:bwc4JK-ESC0w8acc191e-Y1LTC2" then developers will end up
>>> using the text "example" because they don't understand why it's there,
>>> and then it serves no purpose really.’
>>>
>>>
>>> This field must be a URI, as per JAR:
>>>
>>>   request_uri  The absolute URI as defined by RFC3986 [RFC3986] that
>>>  points to the Request Object (Section 2.1) that hol

Re: [OAUTH-WG] oauth - New Meeting Session Request for IETF 106

[Dick Hardt]

I'd like a slot to provide an update on Reciprocal OAuth.
ᐧ

On Fri, Oct 4, 2019 at 2:12 PM Brian Campbell  wrote:

> Hello chairs,
>
> I'd like to request some agenda time to present on:
> https://tools.ietf.org/html/draft-fett-oauth-dpop
>
> Thank you,
> Brian
>
> On Fri, Oct 4, 2019 at 3:09 PM Torsten Lodderstedt <
> tors...@lodderstedt.net> wrote:
>
>> Hi chairs,
>>
>> I would like to request the following slots:
>> - https://tools.ietf.org/html/draft-lodderstedt-oauth-rar
>> 
>> - https://tools.ietf.org/html/draft-lodderstedt-oauth-par
>> 
>> - Security BCP
>>
>> kind regards,
>> Torsten..
>>
>> Am 04.10.2019 um 11:08 schrieb IETF Meeting Session Request Tool <
>> session-requ...@ietf.org>:
>>
>> 
>>
>> A new meeting session request has just been submitted by Hannes
>> Tschofenig, a Chair of the oauth working group.
>>
>>
>> -
>> Working Group Name: Web Authorization Protocol
>> Area Name: Security Area
>> Session Requester: Hannes Tschofenig
>>
>> Number of Sessions: 2
>> Length of Session(s):  1.5 Hours, 1.5 Hours
>> Number of Attendees: 50
>> Conflicts to Avoid:
>> Chair Conflict: acme tls rats sipcore anima
>> Technology Overlap: ace secevent teep suit core tokbind saag
>>
>>
>>
>> People who must be present:
>>  Roman Danyliw
>>  Hannes Tschofenig
>>  Rifaat Shekh-Yusef
>>
>> Resources Requested:
>>
>> Special Requests:
>>
>> -
>>
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> 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.*___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Refresh Tokens

[Dick Hardt]

My recollection of refresh tokens was for security and revocation.

security: By having a short lived access token, a compromised access token 
would limit the time an attacker would have access

revocation: if the access token is self contained, authorization can be revoked 
by not issuing new access tokens. A resource does not need to query the 
authorization server to see if the access token is valid.This simplifies access 
token validation and makes it easier to scale and support multiple 
authorization servers.  There is a window of time when an access token is 
valid, but authorization is revoked. 



On 2011-08-11, at 10:40 AM, Anthony Nadalin wrote:

> Nowhere in the specification is there explanation for refresh tokens, The 
> reason that the Refresh token was introduced was for anonymity. The scenario 
> is that a client asks the user for access. The user wants to grant the access 
> but not tell the client the user's identity. By issuing the refresh token as 
> an 'identifier' for the user (as well as other context data like the 
> resource) it's possible now to let the client get access without revealing 
> anything about the user. Recommend that the above explanation be included so 
> developers understand why the refresh tokens are there.
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Refresh Tokens

[Dick Hardt]

If it was, no one told me.

On 2011-08-11, at 12:41 PM, Anthony Nadalin wrote:

> Anonymity was certainly part of the design for WRAP
>  
> From: Eran Hammer-Lahav [mailto:e...@hueniverse.com] 
> Sent: Thursday, August 11, 2011 12:35 PM
> To: Anthony Nadalin; Dick Hardt
> Cc: OAuth WG (oauth@ietf.org)
> Subject: Re: [OAUTH-WG] Refresh Tokens
>  
> Section 1.5 already covers refresh tokens. There are many use cases for 
> refresh tokens. They are basically a protocol feature used to make 
> scalability and security more flexible. Anonymity was never part of their 
> design, and by the nature of this protocol, is more in the domain of the 
> resource server (based on what information it exposes via its API). In fact, 
> your email if the first such suggestion of anonymity.
>  
> EHL
>  
> From: Anthony Nadalin 
> Date: Thu, 11 Aug 2011 11:15:28 -0700
> To: Dick Hardt 
> Cc: "OAuth WG (oauth@ietf.org)" 
> Subject: Re: [OAUTH-WG] Refresh Tokens
>  
> Many reasons, but none are explained in the specification
>  
> From: Dick Hardt [mailto:dick.ha...@gmail.com] 
> Sent: Thursday, August 11, 2011 10:51 AM
> To: Anthony Nadalin
> Cc: OAuth WG (oauth@ietf.org)
> Subject: Re: [OAUTH-WG] Refresh Tokens
>  
> My recollection of refresh tokens was for security and revocation.
>  
> security: By having a short lived access token, a compromised access token 
> would limit the time an attacker would have access
>  
> revocation: if the access token is self contained, authorization can be 
> revoked by not issuing new access tokens. A resource does not need to query 
> the authorization server to see if the access token is valid.This simplifies 
> access token validation and makes it easier to scale and support multiple 
> authorization servers.  There is a window of time when an access token is 
> valid, but authorization is revoked. 
>  
>  
>  
> On 2011-08-11, at 10:40 AM, Anthony Nadalin wrote:
> 
> 
> 
> Nowhere in the specification is there explanation for refresh tokens, The 
> reason that the Refresh token was introduced was for anonymity. The scenario 
> is that a client asks the user for access. The user wants to grant the access 
> but not tell the client the user's identity. By issuing the refresh token as 
> an 'identifier' for the user (as well as other context data like the 
> resource) it's possible now to let the client get access without revealing 
> anything about the user. Recommend that the above explanation be included so 
> developers understand why the refresh tokens are there.
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>  

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Refresh Tokens

[Dick Hardt]

Reading over your anonymous story at at the bottom, I don't see what difference 
a refresh token has over an access token. You could do the same thing with just 
an access token. Am I missing something?

On 2011-08-11, at 1:30 PM, Anthony Nadalin wrote:

> Could be! But a definite from Yaron.
>  
> From: Dick Hardt [mailto:dick.ha...@gmail.com] 
> Sent: Thursday, August 11, 2011 1:25 PM
> To: Anthony Nadalin
> Cc: Eran Hammer-Lahav; OAuth WG (oauth@ietf.org)
> Subject: Re: [OAUTH-WG] Refresh Tokens
>  
> If it was, no one told me.
>  
> On 2011-08-11, at 12:41 PM, Anthony Nadalin wrote:
> 
> 
> Anonymity was certainly part of the design for WRAP
>  
> From: Eran Hammer-Lahav [mailto:e...@hueniverse.com] 
> Sent: Thursday, August 11, 2011 12:35 PM
> To: Anthony Nadalin; Dick Hardt
> Cc: OAuth WG (oauth@ietf.org)
> Subject: Re: [OAUTH-WG] Refresh Tokens
>  
> Section 1.5 already covers refresh tokens. There are many use cases for 
> refresh tokens. They are basically a protocol feature used to make 
> scalability and security more flexible. Anonymity was never part of their 
> design, and by the nature of this protocol, is more in the domain of the 
> resource server (based on what information it exposes via its API). In fact, 
> your email if the first such suggestion of anonymity.
>  
> EHL
>  
> From: Anthony Nadalin 
> Date: Thu, 11 Aug 2011 11:15:28 -0700
> To: Dick Hardt 
> Cc: "OAuth WG (oauth@ietf.org)" 
> Subject: Re: [OAUTH-WG] Refresh Tokens
>  
> Many reasons, but none are explained in the specification
>  
> From: Dick Hardt [mailto:dick.ha...@gmail.com] 
> Sent: Thursday, August 11, 2011 10:51 AM
> To: Anthony Nadalin
> Cc: OAuth WG (oauth@ietf.org)
> Subject: Re: [OAUTH-WG] Refresh Tokens
>  
> My recollection of refresh tokens was for security and revocation.
>  
> security: By having a short lived access token, a compromised access token 
> would limit the time an attacker would have access
>  
> revocation: if the access token is self contained, authorization can be 
> revoked by not issuing new access tokens. A resource does not need to query 
> the authorization server to see if the access token is valid.This simplifies 
> access token validation and makes it easier to scale and support multiple 
> authorization servers.  There is a window of time when an access token is 
> valid, but authorization is revoked. 
>  
>  
>  
> On 2011-08-11, at 10:40 AM, Anthony Nadalin wrote:
> 
> 
> 
> 
> Nowhere in the specification is there explanation for refresh tokens, The 
> reason that the Refresh token was introduced was for anonymity. The scenario 
> is that a client asks the user for access. The user wants to grant the access 
> but not tell the client the user's identity. By issuing the refresh token as 
> an 'identifier' for the user (as well as other context data like the 
> resource) it's possible now to let the client get access without revealing 
> anything about the user. Recommend that the above explanation be included so 
> developers understand why the refresh tokens are there.
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>  
>  

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Bearer token credentials syntax

[Dick Hardt]

+1.1

On 2011-09-23, at 7:00 AM, Mike Jones wrote:

> James Manger and others pointed out that the current credentials syntax does 
> not comply with RFC 2617, nor does it match the updated credentials syntax 
> contained in HTTPbis, part 7: Authentication.  The current syntax in the 
> bearer token draft is:
>credentials = "Bearer" RWS access-token
>access-token= 1*( quoted-char / <"> )
>  
>quoted-char = ALPHA / DIGIT /
>  "!" / "#" / "$" / "%" / "&" / "'" / "(" / ")" /
>  "*" / "+" / "-" / "." / "/" / ":" / "<" / "=" /
>  ">" / "?" / "@" / "[" / "]" / "^" / "_" / "`" /
>  "{" / "|" / "}" / "~" / "\" / "," / ";"
>  
> The syntax in HTTPbis is:
> credentials = auth-scheme [ 1*SP ( b64token / #auth-param ) ]
>  
> (Note that some of the BNF elements used by part 7 are defined in HTTPbis, 
> part 1: Messaging.)
>  
> To resolve this comment, I plan to change the Bearer Token draft to use this 
> syntax for credentials, matching HTTPbis:
>credentials = "Bearer" 1*SP ( b64token / #auth-param )
>  
> Are people good with this approach?
>  
> Thanks,
> -- Mike
>  
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Possible alternative resolution to issue 26

[Dick Hardt]

slight preference for 3 and E

-- Dick

On 2011-10-03, at 6:56 PM, Mike Jones  wrote:

 As editor, based upon James’ input, I’d like to expand the set of choices
for the working group to consider by adding the possibility of using JSON
string encodings for scope and error_description where the characters used
for the encoding are restricted to the set of 7-bit ASCII characters
compatible with the HTTPbis and RFC 2617 parameter syntaxes.



1.  Using RFC 5987 encoding for the scope parameter.

2.  Continuing to specify no non-ASCII encoding for scope parameter values.

3.  Using JSON string encoding for the scope parameter.



A.  Using RFC 5987 encoding for the error_description parameter.

B.  Continuing to specify UTF-8 encoding for the error_description
parameter.

C.  Using JSON string encoding for the error_description parameter.



As an individual, I’m sympathetic to the argument that RFC 5987 (with
“scope*” and language tags etc.) is overkill for OAuth implementations,
where neither of the sets of strings is intended to be presented to
end-users.  Hence, the possible attractiveness of options 3 and C.



Thoughts from others?



-- Mike



*From:* William Mills [mailto:wmi...@yahoo-inc.com]
*Sent:* Sunday, October 02, 2011 11:01 PM
*To:* Manger, James H; Mike Jones; oauth@ietf.org
*Subject:* Re: [OAUTH-WG] Possible alternative resolution to issue 26



I don't like dropping scope from the WWW-Authenticate responses, because my
current discovery usage requires scope to be returned so that it can be
passed to the auth server if the user is forced to re-authenticate.



+1 for "explicitly restrict scope values to some subset of printable ASCII
in OAuth2 Core. Not being able to support Unicode in a new protocol is
slightly disappointing, but I can live with it."

   --

*From:* "Manger, James H" 
*To:* Mike Jones ; "oauth@ietf.org" <
oauth@ietf.org>
*Sent:* Sunday, October 2, 2011 5:50 AM
*Subject:* Re: [OAUTH-WG] Possible alternative resolution to issue 26

The best solution is to drop the “scope” field from the “WWW-Authenticate:
Bearer ...” response header. “scope” is relevant to an OAuth2-core flow, not
to presenting a bearer token. “scope” could make sense in a
“WWW-Authenticate: OAuth2 ...” response header as long as other necessary
details such as an authorization URI were also provided. Dropping “scope”
and “error_description” (as the error should be described in the response
body) would eliminate these encoding problems.





If the group really wants to keep “scope”, I don’t think RFC 5987 is a good
solution. RFC 5987 might have been ok for adding internationalization
support to long-standing ASCII-only fields in a world of multiple character
sets – but none of that applies here. Having to change the field name from
“scope” to “scope*” when you have a non-ASCII value is the biggest flaw.



The simplest solution is to explicitly restrict scope values to some subset
of printable ASCII in OAuth2 Core. Not being able to support Unicode in a
new protocol is slightly disappointing, but I can live with it.



My preferred escaping solution would be a JSON string, UTF-8 encoded:
json.org, RFC 4627; value in double-quotes; slash is the escape char;
supports Unicode; eg scope="coll\u00E8gues". This is backward-compatible
with HTTP’s quoted-string syntax. It is forward-compatible with UTF-8 HTTP
headers (if that occurs). JSON is well-supported (and required for other
OAuth2 exchanges). [I might suggest json-string to the httpbis group as a
global replacement for quoted-string (or at least as a recommendation for
new fields).]



--

James Manger



*From:* oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] *On Behalf Of
*Mike Jones
*Sent:* Friday, 30 September 2011 4:53 AM
*To:* oauth@ietf.org
*Subject:* [OAUTH-WG] Possible alternative resolution to issue 26



There seems to now be more working group interest in representing non-ASCII
characters in scope strings than had previously been in evidence.  If we
decide to define a standard representation for doing so, using RFC
5987(Character Set and Language
Encoding for Hypertext Transfer Protocol (HTTP)
Header Field Parameters) seems to be the clear choice.  I’d be interested in
knowing how many working group members are in favor of either:



1.  Using RFC 5987 encoding for the scope parameter.

2.  Continuing to specify no non-ASCII encoding for scope parameter values.



As a related issue, some working group members have objected to specifying
UTF-8 encoding of the error_description value, requesting the use of RFC
5987 encoding instead.  I’d also be interested in knowing how many working
group members are in favor of either:



A.  Using RFC 5987 encoding for the error_description parameter.

B.  Continuing to specify UTF-8 encoding for the error_description
parameter.



(As editor, I would make the observation that if

Re: [OAUTH-WG] Possible alternative resolution to issue 26

[Dick Hardt]

I meant 3 and C

-- Dick

On 2011-10-03, at 6:56 PM, Mike Jones  wrote:

 As editor, based upon James’ input, I’d like to expand the set of choices
for the working group to consider by adding the possibility of using JSON
string encodings for scope and error_description where the characters used
for the encoding are restricted to the set of 7-bit ASCII characters
compatible with the HTTPbis and RFC 2617 parameter syntaxes.



1.  Using RFC 5987 encoding for the scope parameter.

2.  Continuing to specify no non-ASCII encoding for scope parameter values.

3.  Using JSON string encoding for the scope parameter.



A.  Using RFC 5987 encoding for the error_description parameter.

B.  Continuing to specify UTF-8 encoding for the error_description
parameter.

C.  Using JSON string encoding for the error_description parameter.



As an individual, I’m sympathetic to the argument that RFC 5987 (with
“scope*” and language tags etc.) is overkill for OAuth implementations,
where neither of the sets of strings is intended to be presented to
end-users.  Hence, the possible attractiveness of options 3 and C.



Thoughts from others?



-- Mike



*From:* William Mills [mailto:wmi...@yahoo-inc.com]
*Sent:* Sunday, October 02, 2011 11:01 PM
*To:* Manger, James H; Mike Jones; oauth@ietf.org
*Subject:* Re: [OAUTH-WG] Possible alternative resolution to issue 26



I don't like dropping scope from the WWW-Authenticate responses, because my
current discovery usage requires scope to be returned so that it can be
passed to the auth server if the user is forced to re-authenticate.



+1 for "explicitly restrict scope values to some subset of printable ASCII
in OAuth2 Core. Not being able to support Unicode in a new protocol is
slightly disappointing, but I can live with it."

   --

*From:* "Manger, James H" 
*To:* Mike Jones ; "oauth@ietf.org" <
oauth@ietf.org>
*Sent:* Sunday, October 2, 2011 5:50 AM
*Subject:* Re: [OAUTH-WG] Possible alternative resolution to issue 26

The best solution is to drop the “scope” field from the “WWW-Authenticate:
Bearer ...” response header. “scope” is relevant to an OAuth2-core flow, not
to presenting a bearer token. “scope” could make sense in a
“WWW-Authenticate: OAuth2 ...” response header as long as other necessary
details such as an authorization URI were also provided. Dropping “scope”
and “error_description” (as the error should be described in the response
body) would eliminate these encoding problems.





If the group really wants to keep “scope”, I don’t think RFC 5987 is a good
solution. RFC 5987 might have been ok for adding internationalization
support to long-standing ASCII-only fields in a world of multiple character
sets – but none of that applies here. Having to change the field name from
“scope” to “scope*” when you have a non-ASCII value is the biggest flaw.



The simplest solution is to explicitly restrict scope values to some subset
of printable ASCII in OAuth2 Core. Not being able to support Unicode in a
new protocol is slightly disappointing, but I can live with it.



My preferred escaping solution would be a JSON string, UTF-8 encoded:
json.org, RFC 4627; value in double-quotes; slash is the escape char;
supports Unicode; eg scope="coll\u00E8gues". This is backward-compatible
with HTTP’s quoted-string syntax. It is forward-compatible with UTF-8 HTTP
headers (if that occurs). JSON is well-supported (and required for other
OAuth2 exchanges). [I might suggest json-string to the httpbis group as a
global replacement for quoted-string (or at least as a recommendation for
new fields).]



--

James Manger



*From:* oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] *On Behalf Of
*Mike Jones
*Sent:* Friday, 30 September 2011 4:53 AM
*To:* oauth@ietf.org
*Subject:* [OAUTH-WG] Possible alternative resolution to issue 26



There seems to now be more working group interest in representing non-ASCII
characters in scope strings than had previously been in evidence.  If we
decide to define a standard representation for doing so, using RFC
5987(Character Set and Language
Encoding for Hypertext Transfer Protocol (HTTP)
Header Field Parameters) seems to be the clear choice.  I’d be interested in
knowing how many working group members are in favor of either:



1.  Using RFC 5987 encoding for the scope parameter.

2.  Continuing to specify no non-ASCII encoding for scope parameter values.



As a related issue, some working group members have objected to specifying
UTF-8 encoding of the error_description value, requesting the use of RFC
5987 encoding instead.  I’d also be interested in knowing how many working
group members are in favor of either:



A.  Using RFC 5987 encoding for the error_description parameter.

B.  Continuing to specify UTF-8 encoding for the error_description
parameter.



(As editor, I would make the observation that if we choose RFC

Re: [OAUTH-WG] Rechartering

[Dick Hardt]

What if the access tokens come from different authoritative servers?

On Oct 26, 2011, at 9:15 AM, Eran Hammer-Lahav wrote:

> Why not just ask for one access token with all the scopes you need, then 
> refresh it by asking for the different subsets you want.
> 
> EHL
> 
>> -Original Message-
>> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
>> Of Dan Taflin
>> Sent: Tuesday, October 25, 2011 3:37 PM
>> To: OAuth WG
>> Subject: Re: [OAUTH-WG] Rechartering
>> 
>> I would like to second Torsten's pitch for the ability to return multiple 
>> access
>> tokens with a single authorization process. The use case for my company is to
>> segment operations into two main categories: protected and confidential. (A
>> possible third category, public, would not require any authorization at all).
>> Protected operations would be user-specific operations that don't involve
>> the passing of any sensitive information, such as image search results tagged
>> with information about whether each image is available for download by that
>> user. Confidential operations would involve passing user data, like user
>> registration or e-commerce. We would like to protect each category of
>> operations with distinct tokens: a general-use token for protected
>> operations, and a secure token for confidential operations.
>> 
>> We could use the scope parameter to specify either "protected" or
>> "confidential". Currently the oauth spec allows a Refresh token to request a
>> new token with reduced scope from the one originally issued, but there is no
>> way to obtain a new token with a completely different scope without doing
>> the full oauth dance a second time.
>> 
>> Dan
>> 
>> -Original Message-
>> From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net]
>> Sent: Thursday, October 20, 2011 3:57 PM
>> To: Hannes Tschofenig
>> Cc: OAuth WG
>> Subject: Re: [OAUTH-WG] Rechartering
>> 
>> Hi all,
>> 
>> my prioritization is driven by the goal to make OAuth the authorization
>> framework of choice for any internet standard protocol, such as WebDAV,
>> IMAP, SMTP or SIP. So let me first explain what is missing from my point of
>> view and explain some thoughts how to fill the gaps.
>> 
>> A standard protocol is defined in terms of resource types and messages by a
>> body (e.g. IETF, OIDF, OMA), (hopefully) implemented in many places, and
>> used by different but deployment-independent clients.
>> OAuth-based protocol specifications must also define scope values (e.g.
>> read, write, send) and their relation to the resource types and messages. The
>> different deployments expose the standard protocol on different resource
>> server endpoints. In my opinion, it is fundamental
>> to clearly distinguish scope values (standardized, static) and
>> resource server addresses (deployment specific) and to manage their
>> relationships. The current scope definition is much to weak and insufficient.
>> Probably, the UMA concepts of hosts, resources sets, and corresponding
>> scopes could be adopted for that purpose.
>> 
>> OAuth today requires clients to register with the service provider before
>> they are deployed. Would you really expect IMAP clients, e.g.
>> Thunderbird, to register with any a-Mail services upfront? So clients should
>> be given a way to register dynamically to the authorization servers. This
>> should also allow us to cover "client instance" aspects.
>> It is interesting to note, that such a mechanism would allow us to get rid of
>> secret-less clients and the one-time usage requirement for authorization
>> codes.
>> 
>> We also assume the client to know the URLs of the resource server and the
>> corresponding authorization server and to use HTTPS server authentication
>> to verify the resource server's authenticity. This is impossible in the 
>> standard
>> scenario. Clients must be able to discover the authorization server a
>> particular resource server relies on at runtime. The discovery mechanism
>> could be specified by the OAuth WG, but could also be part of an application
>> protocols specification. But we MUST find another way to prevent token
>> phishing by counterfeit resource servers.
>> 
>> As one approach, the client could pass the (previously HTTPS
>> validated) resource server's URL with the authorization request. The
>> authorization server should then refuse such requests for any unknown
>> (counterfeit) resource servers. Such an additional parameter could also serve
>> as namespace for scope values and enable service providers to run multiple
>> instances of the same service within a single deployment.
>> 
>> If the additional data enlarges the request payload to much, we could
>> consider to adopt the "request by reference" proposal.
>> 
>> Let's now assume, OAuth is successful in the world of standard protocols and
>> we will see plenty of deployments with a bunch of different OAuth
>> protected resource servers. Shall this servers all be accessible with a 
>> single

Re: [OAUTH-WG] Rechartering

[Dick Hardt]

The authoritative server could be acting as a intermediary for other 
authoritative servers. 

eg. RP would like to get access to both Facebook and Twitter. An intermdiate AS 
could acquire both tokens for the RP.

On Oct 31, 2011, at 3:56 PM, Anthony Nadalin wrote:

> Could be 2 tokens that still fulfill the same scope just that each token is a 
> subset of the requested scope.
> 
> -Original Message-
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of 
> Eran Hammer-Lahav
> Sent: Monday, October 31, 2011 2:17 PM
> To: Dick Hardt
> Cc: OAuth WG; Dan Taflin
> Subject: Re: [OAUTH-WG] Rechartering
> 
> That's a whole different issue as this is about talking to a single server 
> retuning two tokens with different scopes.
> 
> EHL
> 
> ____
> From: Dick Hardt [dick.ha...@gmail.com]
> Sent: Saturday, October 29, 2011 12:07 AM
> To: Eran Hammer-Lahav
> Cc: Dan Taflin; OAuth WG
> Subject: Re: [OAUTH-WG] Rechartering
> 
> What if the access tokens come from different authoritative servers?
> 
> On Oct 26, 2011, at 9:15 AM, Eran Hammer-Lahav wrote:
> 
>> Why not just ask for one access token with all the scopes you need, then 
>> refresh it by asking for the different subsets you want.
>> 
>> EHL
>> 
>>> -Original Message-
>>> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On 
>>> Behalf Of Dan Taflin
>>> Sent: Tuesday, October 25, 2011 3:37 PM
>>> To: OAuth WG
>>> Subject: Re: [OAUTH-WG] Rechartering
>>> 
>>> I would like to second Torsten's pitch for the ability to return 
>>> multiple access tokens with a single authorization process. The use 
>>> case for my company is to segment operations into two main 
>>> categories: protected and confidential. (A possible third category, public, 
>>> would not require any authorization at all).
>>> Protected operations would be user-specific operations that don't 
>>> involve the passing of any sensitive information, such as image 
>>> search results tagged with information about whether each image is 
>>> available for download by that user. Confidential operations would 
>>> involve passing user data, like user registration or e-commerce. We 
>>> would like to protect each category of operations with distinct 
>>> tokens: a general-use token for protected operations, and a secure token 
>>> for confidential operations.
>>> 
>>> We could use the scope parameter to specify either "protected" or 
>>> "confidential". Currently the oauth spec allows a Refresh token to 
>>> request a new token with reduced scope from the one originally 
>>> issued, but there is no way to obtain a new token with a completely 
>>> different scope without doing the full oauth dance a second time.
>>> 
>>> Dan
>>> 
>>> -Original Message-
>>> From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net]
>>> Sent: Thursday, October 20, 2011 3:57 PM
>>> To: Hannes Tschofenig
>>> Cc: OAuth WG
>>> Subject: Re: [OAUTH-WG] Rechartering
>>> 
>>> Hi all,
>>> 
>>> my prioritization is driven by the goal to make OAuth the 
>>> authorization framework of choice for any internet standard protocol, 
>>> such as WebDAV, IMAP, SMTP or SIP. So let me first explain what is 
>>> missing from my point of view and explain some thoughts how to fill the 
>>> gaps.
>>> 
>>> A standard protocol is defined in terms of resource types and 
>>> messages by a body (e.g. IETF, OIDF, OMA), (hopefully) implemented in 
>>> many places, and used by different but deployment-independent clients.
>>> OAuth-based protocol specifications must also define scope values (e.g.
>>> read, write, send) and their relation to the resource types and 
>>> messages. The different deployments expose the standard protocol on 
>>> different resource server endpoints. In my opinion, it is fundamental 
>>> to clearly distinguish scope values (standardized, static) and 
>>> resource server addresses (deployment specific) and to manage their 
>>> relationships. The current scope definition is much to weak and 
>>> insufficient.
>>> Probably, the UMA concepts of hosts, resources sets, and 
>>> corresponding scopes could be adopted for that purpose.
>>> 
>>> OAuth today requires clients to register with the service provider 
>>> before they are deployed. Would you really expect IMAP clien

Re: [OAUTH-WG] SHOULD vs MUST for indicating scope on response when different from client request

[Dick Hardt]

+!

On Jan 20, 2012, at 4:20 PM, Torsten Lodderstedt wrote:

> MUST sounds reasonable 
> 
> 
> 
> Eran Hammer  schrieb:
> The current text:
>  
>If the issued access token scope
>is different from the one requested by the client, the authorization
>server SHOULD include the "scope" response parameter to inform the
>client of the actual scope granted.
>  
> Stephen asked why not a MUST. I think it should be MUST. Any disagreement?
>  
> EHL
>  
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] A Scope Attack against OAuth 2.0

[Dick Hardt]

Some of the more interesting capabilities that an app can ask for are revokable 
by the user later on.

Facebook has an API call

/me/permissions
That lets an app determine what permissions the user has granted the app. If 
need be the app can then ask (or re-ask) for additional scopes. 

Additionally, Facebook could decide an app should have fewer scopes and take 
away privileges from the app. A good app would be able to deal with no longer 
being authorized to perform an action.

I fail to see the security issue here.

-- Dick

On Feb 17, 2012, at 7:40 PM, William Mills wrote:

> I don't think the problem as described is an attack per se, the user is able 
> to modify the rights being granted.  The user is after all in control of what 
> they want to allow.  In this case it looks like FBs implementation is pretty 
> loose with the games apps and there's no guarantee you'll get the rights you 
> want as a game developer.
> 
> What this scenario mean is that the integrity of the request from the game 
> company to FB via the user's context does not have sufficient integrity 
> guarantee.  It is certainly possible for the auth server to have a registry 
> of known clients and expected scopes, and in fact the auth server is expected 
> to communicate to the user what they are approving.
> 
> Can an attacker cause a user to approve a token with an unexpected scope?  
> That would be a big problem.
> 
> From: Wenjie Lin 
> To: oauth@ietf.org 
> Sent: Friday, February 17, 2012 6:07 PM
> Subject: [OAUTH-WG] A Scope Attack against OAuth 2.0
> 
> We describe an attack on OAuth 2.0 (draft-ietf-oauth-v2-23), called scope 
> attack, provide a live-demo of the attack on Facebook, and propose a fix with 
> discussions.
>  
> Scope Attack
> OAuth authorization of services is associated with service agreement scope. 
> For instance, Client provides an online game to User with a service agreement 
> scope A: User authorizes Client to access his profile information and to post 
> messages on his behalf. A malicious User can request for online game with 
> service agreement scope A, manipulate the scope field, and change it to scope 
> B: User authorizes Client to access his profile information. User can still 
> play the games,  yet Client can’t post messages on User’s behalf, as 
> originally agreed.
> OAuth 2.0 authorization code grant and implicit grant are vulnerable to the 
> scope attack.
>  
> A Scope Attack Scenario
> (1) Authorization Server: Facebook (authorization code grant)
> (2) Client: Online gaming company Game. It allows User to play the games with 
> the service agreement scope A: User authorizes Game to access his profile 
> information and post messages on his behalf.
> (3) User: malicious User with an account at Facebook. He attempts to play the 
> games yet without authorizing Game to post messages on his behalf, that is, 
> he changes the scope from A to B: authorization of Client to access his 
> profile information only.
>  
> Attack Workflow
> (1) User requests Game (Client) for permission to play games, instantiating 
> OAuth 2.0 with scope A.
> (2) Game generates an authorization request with a scope specification A, and 
> redirects User to Facebook with the request.
> (3) User manipulates the scope field and changes it to scope B. The modified 
> request is then sent to Facebook.
> (4) User grants the modified request.
> (5) Facebook redirects User back to Game with the authorization code.
> (6) Game exchanges the authorization code for an access token. However it has 
> no knowledge that the scope A has been changed to scope B.
> (7) Game provides online gaming service to User. However, Game can’t post 
> messages on User’s Facebook page.
>  
> A Live-Demo: Facebook and CastleVille (IE and Safari tested)
> Step 1: Login Facebook and visit Facebook Apps and Game page
> https://www.facebook.com/games
> Step 2: Click CastleVille.
> Step 3: When you see the Request for Permission page, instead of
> clicking “Allow”, change the scope field in the URL from your browser from  
> “scope=email%2Cpublish_stream%2Cpublish_actions” to 
> “scope=email%2Cpublish_stream”.
> Step 4: After the modification, press ENTER to send the modified
> request to Facebook. Now you will see the modified Request of Permission page.
> Step 5: Click on “Allow” button and enjoy the game.
> (video: http://www.youtube.com/watch?v=zkmjLa3VU9w)
>  
> Impact
> Client provides services to malicious User yet with the modified service 
> agreement scope by User’s design.
>  
> Manipulating Scope Field
> The scope field in access token response is required ONLY IF Authorization 
> Server observes that the User authorized scope is different than the original 
> scope. Consequently, User can manipulate the scope field so that 
> Authorization Server cannot detect the change of the scope. As a result 
> Client provides the services yet can’t obtain the information that is 
> specified in the scope of the original service agreement.
> Cl

Re: [OAUTH-WG] IIW and OAuth

[Dick Hardt]

I'd also prefer something during IIW schedule (tues - thu)

-- Dick

On 2012-04-16, at 9:42 AM, Justin Richer  wrote:

 Thursday would conflict with IIW sessions proper, and we'd prefer a Friday
morning get together.

 -- Justin

On 04/16/2012 12:27 PM, John Bradley wrote:

Thursday morning works for me as well.

John B.

Sent from my iPad

On 2012-04-16, at 6:14 PM, Phil Hunt 
 wrote:


 Can do, but would prefer a date Tues-Thurs as am flying home Thurs eve.

Phil

@independentidwww.independentid.comphil.h...@oracle.com





On 2012-04-16, at 4:55 AM, Hannes Tschofenig wrote:


 Hi guys,

I was wondering how many of you will be at the upcoming IIW in
Mountain View (or for some other event). IIW will run from Tuesday
(May 1st) to Thursday (May 3rd).

I thought it might be good to useful to get together on the Friday
after the IIW event for a OAuth breakfast chat.
I am sure that there are still a couple of topics that require brainstorming.

Drop me a message if you are able and interested.

Ciao
Hannes

PS: Please do not forget to read the Assertion specs so that we can
get them out of the door.
(And thanks to those who have already read them.)

___
OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth

 ___
OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth



___
OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] [apps-discuss] Web Finger vs. Simple Web Discovery (SWD)

[Dick Hardt]

A couple months ago I was checking out what was up. The AOL and Yahoo endpoints 
no longer worked. The Google one still did.

On Apr 17, 2012, at 3:54 PM, Blaine Cook wrote:

> That's a tricky question - maybe one google can help answer? There are a 
> bunch of projects using webfinger, including status.net, ostatus in general, 
> diaspora, unhosted, freedombox(?), and I'm sure others, but I have no idea 
> how that translates into actual users or profiles.
> 
> Gmail, aol, and yahoo all put up webfinger endpoints, but there hasn't been 
> much movement, I think due to the chicken and egg nature of adoption around 
> decentralized tools.
> 
> b.
> 
> On Apr 17, 2012 11:13 AM, "Tim Bray"  wrote:
> What is the deployment status of these two specs?  Is either deployed
> much at all?  -T
> 
> On Fri, Apr 13, 2012 at 10:45 AM, Murray S. Kucherawy  
> wrote:
> >> -Original Message-
> >> From: apps-discuss-boun...@ietf.org [mailto:apps-discuss-boun...@ietf.org] 
> >> On Behalf Of Stephen Farrell
> >> Sent: Friday, April 13, 2012 9:23 AM
> >> To: oauth@ietf.org WG
> >> Cc: Apps Discuss
> >> Subject: Re: [apps-discuss] [OAUTH-WG] Web Finger vs. Simple Web Discovery 
> >> (SWD)
> >>
> >> So Hannes and Derek and I have been discussing this with the Apps ADs
> >> and Apps-area WG chairs. I've also read the docs now, and after all
> >> that we've decided that this topic (what to do with swd and webfinger)
> >> is best handled in the apps area and not in the oauth WG.
> >>
> >> The logic for that is that 1) the two proposals are doing the same
> >> thing and we don't want two different standards for that, b) this is
> >> not an oauth-specific thing nor is it a general security thing, and c)
> >> there is clearly already interest in the topic in the apps area so its
> >> reasonable for the oauth wg to use that when its ready.
> >>
> >> The appsawg chairs and apps ADs are ok with the work being done there.
> >>
> >> So:-
> >>
> >> - I've asked the oauth chairs to take doing work on swd
> >>   out of the proposed new charter
> >> - It may be that you want to add something saying that
> >>   oauth will use the results of work in the applications
> >>   area on a web discovery protocol as a basis for doing
> >>   the dynamic client registration work here
> >> - Discussion of webfinger and swd should move over to
> >>   the apps-discuss list
> >> - Note: this is not picking one or the other approach,
> >>   the plan is that the apps area will do any selection
> >>   needed and figure out the best starting point for a
> >>   standards-track RFC on web discovery and we'll use their
> >>   fine work for doing more with oauth.
> >
> > Thank you Stephen, I think.  :-)
> >
> > So the discussion on apps-discuss now should be focused on which of the two 
> > should be the basis for forward progress.  I've placed both documents in 
> > "Call for Adoption" state in the datatracker for appsawg.
> >
> > Let the games begin.
> >
> > -MSK
> > ___
> > apps-discuss mailing list
> > apps-disc...@ietf.org
> > https://www.ietf.org/mailman/listinfo/apps-discuss
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] IPR on OAuth bearer

[Dick Hardt]

3) I have read the IPR and I believe I could deploy this specification.

NOTE: I am not a legal expert, but I do have extensive experience with identity 
related patents and after reviewing the claims, I do not believe that the OAuth 
2.0 or OAuth bearer specifications infringe on patent 7272639.

-- Dick

On May 9, 2012, at 2:45 PM, Sam Hartman wrote:

> So, here are statements that  you could make as part of this discussion
> that would be entirely in scope:
> 
> 1) I've read the IPR. Prior to this disclosure I was interested in
> developing|deploying|shipping  an implementation of this
> specification. Now I am not.
> 
> 2) I think you could go so far as to say. Based on this IPR I would no
> longer feel comfortable making an open-source implementation of this
> spec available.
> 
> 3) Or on the other  side: I've reviewed this new IPR and I believe I
> could implement|ship|deploy|whatever this specification.
> 
> Or if you don't like giving out as much information as 1-3:
> 
> 4) I've reviewed the new IPr and I recommend that we not advance this
> standard
> 
> 5) I've reviewed the IPR and I do recommend we advance.
> 
> Obviously, people may weigh statements of the form 1-3 with more value
> than 4-5. However it's really hard to get many organizations to say
> something in the 1-3 range.
> 
> Other valid things to say in such a context include:
> 
> 6) We've successfully obtained any licenses we believe that we need in
> order to implement this specification given the IPR.
> 
> 7) We attempted to obtain the licenses we needed in order to implement
> given this IPR but were unsuccessful.
> 
> believe all the above statements are acceptable. In particular, none of
> them comment on the validity of the IPR nor give legal advice about
> stuff.
> 
> I believe you could even go so far as to say  something like I believe
> that an open-source implementation of this technology is|is not
> important to whether we should standardize it. I believe we've come very
> close to that in the past. 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] OAuth Core -27 Published

[Dick Hardt]

On Jun 8, 2012, at 10:51 AM, Mike Jones wrote:

> The chairs approved publication of OAuth Core draft -27 today.  This version 
> is based upon the proposed changes that I’d circulated to the working group.  
> Changes are:
> ·Adds character set restrictions for error, error_description, and 
> error_uri parameters consistent with the OAuth Bearer spec.
> ·Adds “resource access error response” as an error usage location in 
> the OAuth Extensions Error Registry.
> ·Adds an ABNF for all message elements.
> ·Corrects editorial issues identified during review
>  
> There are still potential issues with some ABNF definitions that need to be 
> discussed by the working group.  I’ll send a separate note about that.  
> Nonetheless, the chairs felt that publishing this version would be a step in 
> the right direction towards completing the Core and Bearer specifications.
>  
> I’ll be publishing an updated Bearer draft shortly that references the 
> changes in -27 in ways that should resolve the outstanding DISCUSS issues 
> against Bearer.
>  
> Thanks to Dick Hart for publishing the draft.

s/Dick Hart/Dick Hardt/

:)



___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] New draft process / editor role

[Dick Hardt]

Mike emailed me the draft and asked if I would publish it.

I reviewed the draft and I thought it captured consensus.

I noted that Hannes had asked Eran to publish the edits a week ago 

There have been numerous indications that Eran has lost interest in continuing 
as editor. Eg. his decision to discontinue his work on the MAC spec.

I viewed it as my duty as an author to maintain forward momentum of the spec.

Eran is still listed as the editor

Can we move forward with the work at hand now?

-- Dick

On Jun 8, 2012, at 6:58 PM, Eran Hammer wrote:

> Today, a new draft of the OAuth 2.0 specification was published.
>  
> * I had nothing to do with this draft. I did not edit or authored it. I 
> didn't know it was being published.
> * The draft was authored by Mike Jones and published by Dick Hardt.
> * Neither one is an editor or an active author of the document.
>  
> Here are the facts:
>  
> * On 5/31 Hannes asked me to publish a new draft with the proposed changes 
> posted by Mike by Sunday 6/3 (within 3 days). The chairs did not offer any 
> reason for requesting such a quick turnaround. It took the chairs weeks to 
> respond to me about the request for ABNF or error text. There wasn't any 
> urgency when it was their task.
> * I promptly replied that I plan to wait until the ABNF is completed before 
> publishing a new draft. The ABNF, which is the only pending DISCUSS for the 
> core specification, is still being actively debated on the list and was 
> clearly presented as work in progress.
> * Hannes did not reply back with any other instructions.
> * Mike replied back trying to speak on behalf of the chairs, suggesting that 
> 'version numbers are cheap'. I replied that my time isn't.
> * At no point did any of the chairs indicated any issue with my publication 
> schedule. The full thread is here: 
> http://www.ietf.org/mail-archive/web/oauth/current/msg09111.html.
> * Today, using Dick Hardt author credit on the document, Mike published his 
> draft. There is no indication that changes were made by someone other than 
> the editor or that the added sections are still a work in progress and 
> pending consensus as is WG practice (e.g. [[ Pending Consensus ]] or [[ 
> Proposed Text]]).
> * No one has offered any explanation as to why the editor was pushed aside 
> and blindsided with a new draft. There was no communication or any attempt to 
> from the chairs, Mike, Dick, or anyone else.
> * After posting the new draft, Mike emailed the IESG to resolve a pending 
> DISCUSS item on the core specification, something that is clearly my role and 
> handled by me so far. I was not included in the email list but received a 
> copy through the tracker system as author.
>  
> Publishing a new draft must be done by a listed author. The only reason Dick 
> and David are listed is historical in regognition of their initial 
> contribution. Both David and Dick offered to remove their name from the top 
> credits in the past (the reason Dick gave at the time was that the document 
> was clearly my work). Using the author credit as a way to sidestep the editor 
> is within the chairs right but that doesn't make it right.
>  
> I have done absolutely nothing to justify taking the document editorial work 
> from me, even temporarily. I have tirelessly published 26 drafts of this 
> documenty. I have been working on this specification for almost 5 years. 
> While the chairs can certainly decide who gets to edit and publish new 
> drafts, there was no reason to do this here, and typically this is done when 
> an editor is unresponsive and has to be removed. In this case, it was the 
> chairs who were unresponsive  and uncommunicative. They didn't think to even 
> give me the courtesy of a head up.
>  
> It is not clear to me what my standing is at this point with regard to this 
> document. I will wait for further information from the AD to decide how to 
> proceed.
>  
> EH
>  
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] New draft process / editor role

[Dick Hardt]

On Jun 9, 2012, at 1:20 PM, Melinda Shore wrote:

> On 6/9/12 12:56 AM, Dick Hardt wrote:
>> Mike emailed me the draft and asked if I would publish it.
>> I reviewed the draft and I thought it captured consensus.
> 
> Chairs call consensus.

Agreed. I thought it captured the consensus that Hannes was referring to when 
he asked the edits to be published.

> 
>> I noted that Hannes had asked Eran to publish the edits a week ago
>> There have been numerous indications that Eran has lost interest in
>> continuing as editor. Eg. his decision to discontinue his work on the
>> MAC spec.
> 
> Okay, but why wasn't Eran at least informed, given that he had *not*
> announced that he would no longer be editing this document?  This sounds
> like a bobble by the chairs and a possible overreach by you, and this is
> something that should be brought to the attention of the working group
> (i.e. the legitimacy of this version of the document is, well,
> questionable) but resolved offline by the chairs and editors.  A public
> apology wouldn't be a terrible thing, either.

I was responding to a request to publish the version from Mike and had the 
impression this was what the chairs wanted.
I apologize for all the confusion this has caused. 

-- Dick
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] proposal of a paragraph to add to the security considerations section

[Dick Hardt]

John

Do you have suggested text per your suggestion below?

-- Dick

On Jun 18, 2012, at 2:04 PM, John Bradley wrote:

> I blogged about this in the hypothetical several months ago. 
> http://www.thread-safe.com/2012/01/problem-with-oauth-for-authentication.html
> 
> Nov Matake and others built some tests and found quite a number of 
> deployments vulnerable. 
> http://www.thread-safe.com/2012/02/more-on-oauth-implicit-flow-application.html
> 
> The bottom line is that OAuth has no explicit audience restriction for 
> tokens,  hence accepting any token outside of the code flow is subject to 
> attack.
> 
> In general it is not a issue for authorization,  it is however a big issue 
> then there is a presumption that the presenter of a token that grants a 
> client access to resource x is the "resource owner" of resource x, when it is 
> possible that the presenter is any client who has ever had a access token for 
> resource x.
> 
> We might want to include the why it is insecure in the security 
> consideration,  otherwise people reading the below will likely ignore the 
> advice as it seems on the surface a touch extreme.
> 
> There are certainly OAuth flows that allow you to do authentication safely,  
> just not all of them without additional precautions.
> 
> That is why openID Connect has a audience restricted id_token similar to 
> Facebook's signed request to allow the implicit flows to be safely used for 
> authentication.
> 
> John B.
> 
> 
> 
> 
> On 2012-06-18, at 4:19 PM, Shuo Chen (MSR) wrote:
> 
>> Hi OAuth group,
>>  
>> This is regarding the recent discussion about an implementation issue of 
>> some cloud services using OAuth for authentication.
>> Derek Atkins and Dick Hardt suggested the possibility to discuss with the 
>> group a paragraph to add to the security considerations section.
>>  
>> Derek’s suggestion:
>>    ===  ===  ===
>> >> Perhaps you could boil it down to a paragraph
>> >> or two for addition to the security considerations section that basically 
>> >> says
>> >> "beware of implementing it *this* way because it leads to *that* attack 
>> >> vector", etc.
>>    ===  ===  ===
>>  
>>  
>> Here is out suggested text:
>>    ===  ===  ===
>> It has been observed that in multiple occasions that the server-side
>> authentication logic takes an access token from the client, then
>> queries the user's profile data from the IdP in order to
>> "authenticate" the user. This implementation must be forbidden. It
>> will allow an untrusted app running on a victim’s client device to
>> work with an attacker’s device to sign into the victim’s account on the 
>> server side.
>>    ===  ===  ===
>>  
>>  
>> Thank you.
>> -Shuo
>> p.s. below is the email thread giving a better context of the discussion.
>>  
>>  
>> > -Original Message-
>> > From: Derek Atkins [mailto:de...@ihtfp.com]
>> > Sent: Monday, June 18, 2012 11:25 AM
>> > To: Shuo Chen (MSR)
>> > Cc: Hannes Tschofenig; rui wang; Stephen Farrell; Yuchen Zhou; Derek
>> > Atkins; Dick Hardt
>> > Subject: Re: [OAUTH-WG] web sso study...
>> > 
>> > Hi,
>> > 
>> > "Shuo Chen (MSR)"  writes:
>> > 
>> >> Hi Hannes, Derek and Stephen,
>> >> 
>> >> Thank you for your replies.
>> >> 
>> >>> First, let me ask whether it is OK if I share your post with the
>> >>> OAuth WG
>> >> 
>> >> Yes, please feel free to share it.
>> >> 
>> >>> Second, could you describe the attack in more details to me?
>> >> 
>> >> Let's consider the mobile+cloud scenario for concreteness (although
>> >> some other scenarios are also applicable). The attack steps are the
>> >> following: suppose Alice's tablet runs a Windows 8 Metro app written
>> >> by attacker Bob. This app is able to request and obtain an access
>> >> token from the IdP (associated with Alice). The app can then send the
>> >> access token to Bob's own tablet. Note that there is no security
>> >> problem up to this point. However the real problem is that some cloud
>> >> services use the access token to query the user's profile data from
>> >> the IdP in order to "authenticate" the user. In this case, Bob's
>> >> tablet will be able to sign into the cloud service as Alice. We have
>

Re: [OAUTH-WG] Report an authentication issue

[Dick Hardt]

On Jun 29, 2012, at 11:06 AM, John Bradley wrote:

> It is nice to know that I may occasionally be correct:)

You must be delighted when it happens! ;)

> While you may assume that it is reasonable for a client with a code to make a 
> request to the token endpoint including it's client_id and the server to only 
> give out the access token if the client_id in the token request matches the 
> one in the original authorization request.   However the spec specifically 
> doesn't require that.

I think that is an error in the spec and should be changed, or text adding 
saying that the client_id SHOULD be checked.

-- Dick
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Report an authentication issue

[Dick Hardt]

If an attacked can modify the communications over TLS between the client and 
the authorization server, then I think there are many other options open to the 
attacker.

-- Dick

On Jun 29, 2012, at 11:53 AM, Phil Hunt wrote:

> I'm not seeing how client id helps if a proxy server is somehow involved with 
> inserting the bearer token as the researchers suggested. 
> 
> Phil
> 
> On 2012-06-29, at 11:30, John Bradley  wrote:
> 
>> I think they only exploited the implicit flow.   
>> 
>> My point was that there is a way you could do the same thing with code if it 
>> is a public client that is not authenticating to the token endpoint.
>> 
>> In general making identity assumptions in the client based on a code or 
>> access_token has risks that are out of scope for OAuth.
>> 
>> We do however want to provide good advice about specific things that can 
>> leave systems insecure when using OAuth.
>> 
>> John B.
>> 
>> On 2012-06-29, at 2:22 PM, Phil Hunt wrote:
>> 
>>> I'm not clear whether the MS Security Researcher hack was with the 
>>> authorization code or the access token. If the latter, the client_id is out 
>>> of the picture isn't it?
>>> 
>>> Phil
>>> 
>>> @independentid
>>> www.independentid.com
>>> phil.h...@oracle.com
>>> 
>>> 
>>> 
>>> 
>>> 
>>> On 2012-06-29, at 11:14 AM, Dick Hardt wrote:
>>> 
>>>> 
>>>> On Jun 29, 2012, at 11:06 AM, John Bradley wrote:
>>>> 
>>>>> It is nice to know that I may occasionally be correct:)
>>>> 
>>>> You must be delighted when it happens! ;)
>>>> 
>>>>> While you may assume that it is reasonable for a client with a code to 
>>>>> make a request to the token endpoint including it's client_id and the 
>>>>> server to only give out the access token if the client_id in the token 
>>>>> request matches the one in the original authorization request.   However 
>>>>> the spec specifically doesn't require that.
>>>> 
>>>> I think that is an error in the spec and should be changed, or text adding 
>>>> saying that the client_id SHOULD be checked.
>>>> 
>>>> -- Dick
>>>> ___
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>> 
>> 

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Preliminary OAuth Core draft -29

[Dick Hardt]

Hi Mike

Reading over the spec, I think some more color in 4.2 on the risks of the 
Implicit Grant and where it makes sense and where it does not is in order. 
Also, this should be in Section 9.

Thoughts?

-- Dick

On Jul 9, 2012, at 12:08 AM, Mike Jones wrote:

> A preliminary version of OAuth core draft -29 is attached for the working 
> group’s consideration and discussion on today’s call.  I believe that this 
> addresses all issues that have been raised, including Julian’s issues about 
> the ABNF, character sets, and form encoding.  Changes are:
>  
> Added "MUST" to "A public client that was not issued a client password MUST 
> use the client_id request parameter to identify itself when sending requests 
> to the token endpoint" and added text explaining why this must be so.
> Added that the authorization server MUST "ensure the authorization code was 
> issued to the authenticated confidential client or to the public client 
> identified by the client_id in the request".
> Added Security Considerations section "Misuse of Access Token to Impersonate 
> Resource Owner at Public Client".
> Deleted ";charset=UTF-8" from examples formerly using "Content-Type: 
> application/x-www-form-urlencoded;charset=UTF-8".
> Added the phrase "and a character encoding of UTF-8" when describing how to 
> send requests using the HTTP request entity-body, per Julian Reschke's 
> suggestion.
> Added "The ABNF below is defined in terms of Unicode code points [UNICODE5]; 
> these characters are typically encoded in UTF-8".
> For symmetry when using HTTP Basic authentication, also apply the 
> application/x-www-form-urlencoded encoding to the client password, just as 
> was already done for the client identifier.
> Reduced multiple blank lines around artwork elements to single blank lines.
> Removed Eran Hammer's name from the author list, at his request. Dick Hardt 
> is now listed as the editor.
>  
> Best wishes,
> -- Mike
>  
>  preliminary.html> preliminary.pdf> preliminary.xml>___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Preliminary OAuth Core draft -29

[Dick Hardt]

On Jul 9, 2012, at 1:21 PM, Justin Richer wrote:

> Implicit grant makes perfect sense when the user agent and client are 
> collapsed into a single entity. In other words, if your client is inside the 
> user agent then doing a code flow doesn't actually buy you any extra security.

It protects the client from an attacker replacing the access token.

> This is the driving design decision behind having it in there, and from my 
> perspective that's clear from the current text.

I think the reasons for implicit flow are captured in 1.3.2, and it would be 
useful to point to them in 4.2 

> 
> In a similar manner, the client credentials flow came about from collapsing 
> the client with the resource owner, effectively putting the resource owner 
> inside the client.

It can be thought of like that, but that is not where it came from.

> In this case the authorization step doesn't make any sense and doing a code 
> flow doesn't buy you any greater security, either.


One can think of the client credential flow as the client already having the 
code and that the authorization happened out of band. No need to change any 
copy.

On 07/09/2012 01:31 PM, Dick Hardt wrote:
> Hi Mike
> 
> Reading over the spec, I think some more color in 4.2 on the risks of the 
> Implicit Grant and where it makes sense and where it does not is in order. 
> Also, this should be in Section 9.
> 
> Thoughts?
> 
> -- Dick
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Preliminary OAuth Core draft -29

[Dick Hardt]

Much appreciated Julian!

On Jul 12, 2012, at 1:31 AM, Julian Reschke wrote:

> On 2012-07-09 17:01, Julian Reschke wrote:
>> On 2012-07-09 16:48, Mike Jones wrote:
>>> HTML5 is not cited because it's a working draft - not an approved
>>> standard.  In what way is "the definition of the media type in HTML4
>>> is known to be insufficient"?  People have been successfully
>>> implementing form-urlencoding with it for quite some time. :-)  Is
>>> there a specific wording change that you'd suggest that we make that
>>> doesn't involve citing a working draft, rather than an approved standard?
>> 
>> For instance, the HTML4 "definition" doesn't even mention what to do
>> with non-ASCII characters.
>> 
>> I understand that it's not particularly attractive, but citing HTML4
>> just because it's a "standard" isn't really helpful for people who
>> actually follow the link and try to understand what needs to be
>> implemented.
>> ...
> 
> Here's an attempt to describe the encoding in terms of HTML4, plus additional 
> instruction. This would need to be referenced anyway where the spec currently 
> refers to the HTML4 media type definition:
> 
> -- snip --
> Appendix X. Use of the application/x-www-form-urlencoded Media Type
> 
> At the time of publication of this specification, the 
> "application/x-www-form-urlencoded" media type was defined in Section 17.13.4 
> of [HTML4], but not registered in the IANA media types registry 
> (). Furthermore, the 
> definition is incomplete as it does not consider non-US-ASCII characters.
> 
> To address this shortcoming, when generating payloads using this media type, 
> names and values MUST be encoded using the "UTF-8" character encoding scheme 
> ([RFC3629]) first; the resulting octet sequence then needs to be further 
> encoded using the escaping rules defined in [HTML4].
> 
> When parsing data from a payload using this media type, the names and values 
> resulting from reversing the name/value encoding consequently need to be 
> treated as octet sequences, to be decoded using the "UTF-8" character 
> encoding scheme.
> 
> Example: A value consisting of the six Unicode code points (1) U+0020 
> (SPACE), (2) U+0025 (PERCENT SIGN), (3) U+0026 (AMPERSAND), (4) U+002B (PLUS 
> SIGN), (5) U+00A3 (POUND SIGN), and (6) U+20AC (EURO SIGN) would be encoded 
> into the octet sequence below (using hexadecimal notation):
> 
>  20 25 26 2B C2 A3 E2 82 AC
> 
> and then represented in the payload as:
> 
>  +%25%26%2B%C2%A3%E2%82%AC
> 
> -- snip --
> 
> Best regards, Julian
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Mail regarding draft-ietf-oauth-v2

[Dick Hardt]

Charles

Thanks for the suggestion. I just did publish a new draft that included a 
number of items that had been discussed and I would like to get some feedback 
on your suggestion before incorporating it (or not).

Does anyone have feedback on the change below? (+/-)

-- Dick

On Jul 12, 2012, at 1:45 PM, Honton, Charles wrote:

> E. Hammer, D. Recordon, D. Hardt, et.al,
> 
> I'm looking at draft 28 (http://tools.ietf.org/html/draft-ietf-oauth-v2-28).
> 
> In Section 5.2 the error code should probably include:
> 
>   server_error
>The authorization server encountered an unexpected
>condition which prevented it from fulfilling the request.
>  temporarily_unavailable
>The authorization server is currently unable to handle
>the request due to a temporary overloading or maintenance
>of the server.
> 
> 
> Regards,
> chas
> 

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Mail regarding draft-ietf-oauth-v2

[Dick Hardt]

Great suggestion Charles. I think this is a good clarification. I'll adjust the 
copy you sent to be what follows in a new draft published tomorrow evening 
(Sunday PT) unless someone objects.

-- Dick

In both sections 4.1.2.1 and 4.2.2.1:
 
  server_error
   The authorization server encountered an unexpected
   condition which prevented it from fulfilling the request. 
   This error code is needed because a 500 Internal Server
   Error HTTP status code cannot be returned to the client
   via a HTTP redirect.
  temporarily_unavailable
   The authorization server is currently unable to handle
   the request due to a temporary overloading or maintenance
   of the server.  This error code is needed because a 503 Service
   Unavailable HTTP status code cannot be returned to the client
   via a HTTP redirect.
 

On Jul 13, 2012, at 9:45 AM, Honton, Charles wrote:

> Just to make sure I understand…
> 
> If  the Authorization Server returns a 5xx,  the User-Agent will immediately 
> display a error message.
> 
> If  the Authorization Server returns an error code in the redirect,  the 
> Client can take alternative actions or appropriately message the error.
> 
> If this is correct, perhaps a slight change in wording will explain the lack 
> of symmetry in the error codes. 
> 
> In both sections 4.1.2.1 and 4.2.2.1:
> 
>   server_error
>The authorization server encountered an unexpected
>condition which prevented it from fulfilling the request. 
>  Using this error code allows the Client to handle this 
>condition instead of the User-Agent
>  temporarily_unavailable
>The authorization server is currently unable to handle
>the request due to a temporary overloading or maintenance
>of the server.  Using this error code allows the Client 
>to handle this condition instead of the User-Agent
> 
> Thanks,
> chas
> 
> From: John Bradley 
> Date: Friday, July 13, 2012 9:08 AM
> To: Charles Honton 
> Cc: Dick Hardt , "draft-ietf-oauth...@tools.ietf.org" 
> , "oauth@ietf.org WG" 
> Subject: Re: [OAUTH-WG] Mail regarding draft-ietf-oauth-v2
> 
> 4.2.2.1 and 4.1.2.1 are error codes that are returned to the client through 
> the browser via a 302 redirect.
> 
> You can't send a 5xx error via a 302 redirect.
> 
> That is why those need error messages specific to OAuth.  
> 
> Errors not being sent via redirect use normal http error codes.
> 
> I thought that was clear.  Is there some general confusion on this?
> 
> John B.
> On 2012-07-13, at 11:55 AM, Honton, Charles wrote:
> 
>> Great! Because this question has come up multiple times, perhaps the rfc 
>> could explain the use of 5xx return code in addition to error_code.
>> 
>> I must be missing something.  Why are  server_error and 
>> temporarily_unavailable specified in sections 4.2.2.1 and 4.1.2.1?  Is there 
>> a distinction between 5xx return code and error_code in these cases?
>> 
>> Chas
>> 
>> From: John Bradley 
>> Date: Friday, July 13, 2012 4:04 AM
>> To: Dick Hardt 
>> Cc: Charles Honton , 
>> "draft-ietf-oauth...@tools.ietf.org" , 
>> "oauth@ietf.org WG" 
>> Subject: Re: [OAUTH-WG] Mail regarding draft-ietf-oauth-v2
>> 
>> FRom what I can see in a similar discussion Eran pointed out that this is a 
>> direct communication, communication between the client and token endpoint.
>> 
>> Server Error and temporarily unavailable are not OAuth specific and are 
>> handled by existing HTTP error codes.
>> 
>> I don't see a need for a change.
>> 
>> Unless something else dramatic comes up I would like to see draft 29 go to 
>> the RFC editor.
>> 
>> (Though one person mentioned to me that 30 is a nicer number:)
>> 
>> John B.
>> 
>> On 2012-07-12, at 8:09 PM, Dick Hardt wrote:
>> 
>>> Charles
>>> 
>>> Thanks for the suggestion. I just did publish a new draft that included a 
>>> number of items that had been discussed and I would like to get some 
>>> feedback on your suggestion before incorporating it (or not).
>>> 
>>> Does anyone have feedback on the change below? (+/-)
>>> 
>>> -- Dick
>>> 
>>> On Jul 12, 2012, at 1:45 PM, Honton, Charles wrote:
>>> 
>>>> E. Hammer, D. Recordon, D. Hardt, et.al,
>>>> 
>>>> I'm looking at draft 28 
>>>> (http://tools.ietf.org/html/draft-ietf-oauth-v2-28).
>>>> 
>>>> In Sectio

Re: [OAUTH-WG] draft-ietf-oauth-v2

[Dick Hardt]

Thanks for the feedback Michael.

4.1.2 is where the authorization code is first talked about, and it makes sense 
to discuss how it is generated and used at that point. I can see how it might 
also be useful to put it in 4.1.3. Note that this is this is RECOMMENDED as 
opposed to MUST so it does not flow into "The authorization server MUST" list 
of points.

Personally, I don't see a need to change. Anyone else have an opinion on this?

-- Dick

On Jul 17, 2012, at 2:22 PM, Michael Scalia wrote:

> Dear OAuth Authors,
> 
> I'm not sure if this is the right way to suggest an edit to the current OAuth 
> draft.  Please let me know if I should use a different route.
> 
> Section 4.1.2 Authorization Response includes the text, "If an authorization 
> code is used more than once, the authorization server MUST deny the request 
> and SHOULD revoke (when possible) all tokens previously issued based on that 
> authorization code.  The authorization code is bound to the client identifier 
> and redirection URI."
> 
> I believe this text is in the wrong place.  A client does not supply the 
> authorization code to the authorization endpoint.  It supplies it to the 
> token endpoint.  This should move to 4.1.3. Access Token Request, in the list 
> of bulleted items under "The authorization server MUST".
> 
> Thanks for all your work on this protocol.
> 
> Regards,
> Michael Scalia

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] draft-ietf-oauth-v2

[Dick Hardt]

Thanks for the implementation feedback Michael.

-- Dick

On Jul 17, 2012, at 3:46 PM, Michael Scalia wrote:

> Thanks for your response, Dick, and for pointing out that this is 
> RECOMMENDED.  I'll just say one more thing about this.  While implementing 
> the token endpoint of an authorization server, I naturally looked for the 
> things I needed to account for in the request under 4.1.3  Access Token 
> Request.  I missed this because it wasn't with the other information about 
> access token requests.  Others may miss it as well, for the same reason.  
> Just happened to notice this today under 4.1.2 while re-reading the spec.
> 
> Regards,
> Michael
> 
> On Tue, Jul 17, 2012 at 6:09 PM, Dick Hardt  wrote:
> Thanks for the feedback Michael.
> 
> 4.1.2 is where the authorization code is first talked about, and it makes 
> sense to discuss how it is generated and used at that point. I can see how it 
> might also be useful to put it in 4.1.3. Note that this is this is 
> RECOMMENDED as opposed to MUST so it does not flow into "The authorization 
> server MUST" list of points.
> 
> Personally, I don't see a need to change. Anyone else have an opinion on this?
> 
> -- Dick
> 
> On Jul 17, 2012, at 2:22 PM, Michael Scalia wrote:
> 
> > Dear OAuth Authors,
> >
> > I'm not sure if this is the right way to suggest an edit to the current 
> > OAuth draft.  Please let me know if I should use a different route.
> >
> > Section 4.1.2 Authorization Response includes the text, "If an 
> > authorization code is used more than once, the authorization server MUST 
> > deny the request and SHOULD revoke (when possible) all tokens previously 
> > issued based on that authorization code.  The authorization code is bound 
> > to the client identifier and redirection URI."
> >
> > I believe this text is in the wrong place.  A client does not supply the 
> > authorization code to the authorization endpoint.  It supplies it to the 
> > token endpoint.  This should move to 4.1.3. Access Token Request, in the 
> > list of bulleted items under "The authorization server MUST".
> >
> > Thanks for all your work on this protocol.
> >
> > Regards,
> > Michael Scalia
> 
> 

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Proposed note to RFC Editor

[Dick Hardt]

+1

On Jul 26, 2012, at 3:06 PM, Mike Jones wrote:

> +1
> 
> Given that the current spec inadvertently broke both the SAML profile and JWT 
> profile, I believe we need to make these changes.
> 
>   -- Mike
> 
> -Original Message-
> From: Brian Campbell [mailto:bcampb...@pingidentity.com] 
> Sent: Thursday, July 26, 2012 1:56 PM
> To: John Bradley
> Cc: oauth WG; Mike Jones
> Subject: Re: Proposed note to RFC Editor
> 
> I agree with the proposed changes and they do adequately address the concerns 
> I raised in a previous message about the unintended breaking changes 
> introduced in 29. Thanks for writing that up John.
> 
> On Thu, Jul 26, 2012 at 2:33 PM, John Bradley  wrote:
>> The changes introduced in Draft 29 had unintended consequences on 
>> parts of the spec caused by Sec 4.3,  4.4 and 6 referencing Sec 3.2.1 
>> as part of client authentication.
>> 
>> This change restricts the requirement to send client_id to only Sec 
>> 4.1.4 for clients that are not authenticated per Sec 3.2.1
>> 
>> 
>> 
>> 
>> Section 3.2.1
>> 
>> 
>>  A public client that was not issued a client password MUST use the
>>  "client_id" request parameter to identify itself when sending
>>  requests to the token endpoint.  This allows the authorization server
>>  to ensure that the code was issued to the same client.  Sending
>>  "client_id" prevents the client from inadvertently accepting a code
>>  intended for a client with a different "client_id".  This protects
>>  the client from substitution of the authentication code.  (It
>>  provides no additional security for the protected resource.)
>> 
>> 
>> Change  to
>> 
>>  A client MAY use the "client_id" request parameter to identify itself
>>  when sending requests to the token endpoint.
>>  In the "authorization_code" grant_type request to the token endpoint,
>>  an unauthenticated client sends "client_id" to prevent itself from
>>  inadvertently accepting a code
>>  intended for a client with a different "client_id".  This protects
>>  the client from substitution of the authentication code.  (It
>>  provides no additional security for the protected resource.)
>> 
>> 
>> ** This allows any client to send client ID and explains the threat to code.
>> 
>> 
>> 4.1.3.  Access Token Request
>> 
>> 
>> 
>> Add
>>  client_id
>>REQUIRED if the client is NOT authenticating with the
>>authorization server as described in Section 3.2.1
>> 
>> 
>> 
>> 
>> ** This makes client_id only REQUIRED for the code flow if the client 
>> is not otherwise authenticated.
>> 
>> Change
>> 
>> 
>> ensure the authorization code was issued to the authenticated
>> confidential client or to the public client identified by the
>> "client_id" in the request,
>> 
>> 
>> To:
>> ensure the authorization code was issued to the authenticated
>> confidential client, or if the client is public, ensure the code was
>> issued to "client_id" in the request,
>> 
>> 
>> ** That removes the implication of authentication.
>> 
>> 
>> 
> 
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] Fwd: Approved: draft-ietf-oauth-v2

[Dick Hardt]

FYI

Begin forwarded message:

> From: Stephen Farrell 
> Subject: Approved: draft-ietf-oauth-v2
> Date: August 1, 2012 3:53:56 PM PDT
> Resent-To: dick.ha...@gmail.com, d...@fb.com
> Resent-To: de...@ihtfp.com, hannes.tschofe...@gmx.net,
> To: draft-ietf-oauth...@tools.ietf.org, IESG , 
> "oauth-cha...@tools.ietf.org" 
> 
> 
> Dear secretariat folks,
> 
> draft-ietf-oauth-v2 is approved, the RFC editor notes are correct.
> Please shoot it off to the RFC editor.
> 
> Thanks,
> Stephen.

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] Fwd: [IANA #596671] Protocol Action: 'The OAuth 2.0 Authorization Framework' to Proposed Standard (draft-ietf-oauth-v2-31.txt)

[Dick Hardt]

Would appreciate a few others checking to make sure the IANA entries are valid. 

-- Dick

Begin forwarded message:

> From: "Amanda Baber via RT" 
> Subject: [IANA #596671] Protocol Action: 'The OAuth 2.0 Authorization 
> Framework' to Proposed Standard (draft-ietf-oauth-v2-31.txt) 
> Date: August 7, 2012 5:34:26 PM PDT
> Cc: dick.ha...@gmail.com, oauth-cha...@tools.ietf.org, 
> oauth-...@tools.ietf.org
> Reply-To: drafts-appro...@iana.org
> 
> Dear Author:
> 
> ATTENTION: A RESPONSE TO THIS MESSAGE IS NEEDED 
> 
> We have completed the IANA Actions for RFC-to-be
> draft-ietf-oauth-v2-31
> 
> IANA has created the OAuth Access Token Types, OAuth Parameters, OAuth
> Authorization Endpoint Response Types, and OAuth Extensions Errors
> registries at
> 
> http://www.iana.org/assignments/oauth-parameters
> 
> 
> Please let us know whether the above IANA Actions look OK. As 
> soon as we receive your confirmation, we'll notify the RFC Editor 
> that this document's IANA Actions are complete. 
> 
> Thanks,
> 
> Amanda Baber
> ICANN/IANA
> 

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] [IANA #596671] Protocol Action: 'The OAuth 2.0 Authorization Framework' to Proposed Standard (draft-ietf-oauth-v2-31.txt)

[Dick Hardt]

Hello Amanda (or whoever :)

It would be nice if the OAuth Parameters were listed alphabetical. 

Also, the reference for the OAuth Access Token Types registry should be 
http://tools.ietf.org/html/draft-ietf-oauth-v2-31 - 
nothttp://tools.ietf.org/html/draft-ietf-oauth-urn-sub-ns-06.

-- Dick

On Aug 7, 2012, at 5:34 PM, Amanda Baber via RT wrote:

> Dear Author:
> 
> ATTENTION: A RESPONSE TO THIS MESSAGE IS NEEDED 
> 
> We have completed the IANA Actions for RFC-to-be
> draft-ietf-oauth-v2-31
> 
> IANA has created the OAuth Access Token Types, OAuth Parameters, OAuth
> Authorization Endpoint Response Types, and OAuth Extensions Errors
> registries at
> 
> http://www.iana.org/assignments/oauth-parameters
> 
> 
> Please let us know whether the above IANA Actions look OK. As 
> soon as we receive your confirmation, we'll notify the RFC Editor 
> that this document's IANA Actions are complete. 
> 
> Thanks,
> 
> Amanda Baber
> ICANN/IANA
> 

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01

[Dick Hardt]

On Aug 9, 2012, at 9:52 AM, William Mills wrote:

> I find the idea of starting from scratch frustrating.  MAC solves a set of 
> specific problems and has a well defined use case.  It's symmetric key based 
> which doesn't work for some folks, and the question is do we try to develop 
> something that supports both PK and SK, or finish the SK use case and then 
> work on a PK based draft.
> 
> I think it's better to leave them separate and finish out MAC which is *VERY 
> CLOSE* to being done.

Who is interested in MAC? People can use OAuth 1.0 if they prefer that model. 

For my projects, I prefer the flexibility of a signed or encrypted JWT if I 
need holder of key.

Just my $.02

-- Dick  

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01

[Dick Hardt]

As an implementer, I have an app that accesses 10 different resources. Some are 
OAuth 1.0A, some are a variant of OAuth 2. All have a slightly different code 
path since each resource is its own beautiful snowflake. I did not use any 
libraries for OAuth 2. Supporting MAC would give me yet another library to 
integrate with.

I'd be interested in what signing problems OAuth 1.0A has. I have my own list 
of how writing to OAuth 1.0A is hard.

On Aug 9, 2012, at 10:53 AM, William Mills wrote:

> MAC fixes the signing problems encountered in OAuth 1.0a, yes there are 
> libraries out there for OAuth 1.0a.  MAC fits in to the OAuth 2 auth model 
> and will provide for a single codepath for sites that want to use both Bearer 
> and MAC.
> 
> From: Dick Hardt 
> To: William Mills  
> Cc: "oauth@ietf.org"  
> Sent: Thursday, August 9, 2012 10:27 Aa
> Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01
> 
> 
> On Aug 9, 2012, at 9:52 AM, William Mills wrote:
> 
>> I find the idea of starting from scratch frustrating.  MAC solves a set of 
>> specific problems and has a well defined use case.  It's symmetric key based 
>> which doesn't work for some folks, and the question is do we try to develop 
>> something that supports both PK and SK, or finish the SK use case and then 
>> work on a PK based draft.
>> 
>> I think it's better to leave them separate and finish out MAC which is *VERY 
>> CLOSE* to being done.
> 
> Who is interested in MAC? People can use OAuth 1.0 if they prefer that model. 
> 
> For my projects, I prefer the flexibility of a signed or encrypted JWT if I 
> need holder of key.
> 
> Just my $.02
> 
> -- Dick  
> 
> 
> 

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01

[Dick Hardt]

Yes, sort of.

I blew two days debugging my code accessing Twitter.

We had intermittent failures. It would work for hours, and then fail for hours.

Eventually I noticed that we were calling http://api.twitter.com instead of 
https://api.twitter.com. Once we changed that it worked fine. 

On Aug 9, 2012, at 1:47 PM, William Mills wrote:

> Mostly it's around making sure you get the signature base string constructed 
> right in my experience.
> 
> From: Dick Hardt 
> To: William Mills  
> Cc: Dick Hardt ; "oauth@ietf.org"  
> Sent: Thursday, August 9, 2012 12:48 PM
> Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01
> 
> As an implementer, I have an app that accesses 10 different resources. Some 
> are OAuth 1.0A, some are a variant of OAuth 2. All have a slightly different 
> code path since each resource is its own beautiful snowflake. I did not use 
> any libraries for OAuth 2. Supporting MAC would give me yet another library 
> to integrate with.
> 
> I'd be interested in what signing problems OAuth 1.0A has. I have my own list 
> of how writing to OAuth 1.0A is hard.
> 
> On Aug 9, 2012, at 10:53 AM, William Mills wrote:
> 
>> MAC fixes the signing problems encountered in OAuth 1.0a, yes there are 
>> libraries out there for OAuth 1.0a.  MAC fits in to the OAuth 2 auth model 
>> and will provide for a single codepath for sites that want to use both 
>> Bearer and MAC.
>> 
>> From: Dick Hardt 
>> To: William Mills  
>> Cc: "oauth@ietf.org"  
>> Sent: Thursday, August 9, 2012 10:27 Aa
>> Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01
>> 
>> 
>> On Aug 9, 2012, at 9:52 AM, William Mills wrote:
>> 
>>> I find the idea of starting from scratch frustrating.  MAC solves a set of 
>>> specific problems and has a well defined use case.  It's symmetric key 
>>> based which doesn't work for some folks, and the question is do we try to 
>>> develop something that supports both PK and SK, or finish the SK use case 
>>> and then work on a PK based draft.
>>> 
>>> I think it's better to leave them separate and finish out MAC which is 
>>> *VERY CLOSE* to being done.
>> 
>> Who is interested in MAC? People can use OAuth 1.0 if they prefer that 
>> model. 
>> 
>> For my projects, I prefer the flexibility of a signed or encrypted JWT if I 
>> need holder of key.
>> 
>> Just my $.02
>> 
>> -- Dick  
>> 
>> 
>> 
> 
> 
> 

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01

[Dick Hardt]

On Aug 9, 2012, at 1:08 PM, Justin Richer wrote:

> With MAC, you should be able to re-use about 80-90% of your existing codepath 
> that's in place for Bearer, simplifying the setup below. 

That makes no sense, I would be adding MAC to the sites that support MAC in 
addition to OAuth 1.0A or OAuth 2.0

> 
> I would figure that the "variant of OAuth2" issue is a red herring because 
> not everyone out there is fully spec compliant. If they were, you wouldn't 
> have so many beautiful snowflakes.


Being consistent in the spec would help, but likely would just give me 
snowflakes that look more like each other.

There are many aspects of the OAuth dance that are implementation dependent and 
it is simpler to just have a separate method for each one that deals with those 
unique characteristics. Note this is not theory, this is practice. Different 
modules was not an issue. Not having to use a library to sign requests and 
being able to use CURL or a browser to see what a request returned had a HUGE 
productivity gain for OAuth 2.0 implementations over OAuth 1.0A implemetations. 

> 
>  -- Justin
> 
> On 08/09/2012 03:48 PM, Dick Hardt wrote:
>> As an implementer, I have an app that accesses 10 different resources. Some 
>> are OAuth 1.0A, some are a variant of OAuth 2. All have a slightly different 
>> code path since each resource is its own beautiful snowflake. I did not use 
>> any libraries for OAuth 2. Supporting MAC would give me yet another library 
>> to integrate with.
>> 
>> I'd be interested in what signing problems OAuth 1.0A has. I have my own 
>> list of how writing to OAuth 1.0A is hard.
>> 
>> On Aug 9, 2012, at 10:53 AM, William Mills wrote:
>> 
>>> MAC fixes the signing problems encountered in OAuth 1.0a, yes there are 
>>> libraries out there for OAuth 1.0a.  MAC fits in to the OAuth 2 auth model 
>>> and will provide for a single codepath for sites that want to use both 
>>> Bearer and MAC.
>>> 
>>> From: Dick Hardt 
>>> To: William Mills  
>>> Cc: "oauth@ietf.org"  
>>> Sent: Thursday, August 9, 2012 10:27 Aa
>>> Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01
>>> 
>>> 
>>> On Aug 9, 2012, at 9:52 AM, William Mills wrote:
>>> 
>>>> I find the idea of starting from scratch frustrating.  MAC solves a set of 
>>>> specific problems and has a well defined use case.  It's symmetric key 
>>>> based which doesn't work for some folks, and the question is do we try to 
>>>> develop something that supports both PK and SK, or finish the SK use case 
>>>> and then work on a PK based draft.
>>>> 
>>>> I think it's better to leave them separate and finish out MAC which is 
>>>> *VERY CLOSE* to being done.
>>> 
>>> Who is interested in MAC? People can use OAuth 1.0 if they prefer that 
>>> model. 
>>> 
>>> For my projects, I prefer the flexibility of a signed or encrypted JWT if I 
>>> need holder of key.
>>> 
>>> Just my $.02
>>> 
>>> -- Dick  
>>> 
>>> 
>>> 
>> 
>> 
>> 
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
> 

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01

[Dick Hardt]

As an implementor, I would pick a signed JWT over OAuth 1.0A. Just saying.

Given that, there is also a clear need for signing an HTTP(S) request as some 
sites are choosing OAuth 1.0A over OAuth 2.0 because they don't want to use 
bearer tokens. 

I never followed what MAC solved that OAuth 1.0A did not solve. Would someone 
elaborate? We do have an RFC for signing requests, there are lots of libraries 
already. Why the desire to reinvent OAuth 1.0A?

-- Dick

On Aug 10, 2012, at 8:00 AM, Rob Richards wrote:

> I think you nailed it which that statement. Up until now it as been back and 
> forth about one or the other. Personally I prefer to used layered security 
> and not relying on a single point of attack. It's unrealistic to say everyone 
> is going to want/need/be able to use (take your pick) signed/encrypted JWT. 
> MAC at least offers an alternative, less complicated solution.
> 
> Rob
> 
> On 8/10/12 10:41 AM, Richer, Justin P. wrote:
>> What about security in depth? Signing + TLS is more secure than either 
>> alone, isn't it?
>> 
>>  -- Justin
>> 
>> On Aug 10, 2012, at 3:01 AM, Hannes Tschofenig wrote:
>> 
>>> Hi Bill,
>>> 
>>> thanks for the feedback. Let's have a look at this use case:
>>> 
>>> You need to provide me a bit more information regarding your use case. 
>>> Could you please explain
>>> 
>>> 1) Who is authenticated to whom?
>>> 2) What plaintext connection are you talking about?
>>> 3) What is the problem with encrypted connections? Is this again the "TLS 
>>> has so bad performance" argument?
>>> 4) Since you are talking about cookies and making them more secure are you 
>>> trying to come up with a general solution to better cookie security - a 
>>> topic others are working on as well.
>>> 5) What is the threat you are concerned about?
>>> 
>>> Ciao
>>> Hannes
>>> 
>>> PS: I would heavily argue against standardize a security mechanism that 
>>> offers weaker protection than bearer when the entire argument has always 
>>> been "Bearer is so insecure and we need something stronger."
>>> 
>>> On Aug 9, 2012, at 9:43 PM, William Mills wrote:
>>> 
>>>> OK, I'll play and start documenting the use cases.
>>>> 
>>>> Use case #1: Secure authentication in plain text connections:
>>>> 
>>>> Some applications need a secure form authorization, but do not want or 
>>>> need the overhead of encrypted connections.  HTTP cookies and their ilk 
>>>> are replayable credentials and do not satisfy this need.   the MAC scheme 
>>>> using signed HTTP authorization credentials offer the capability to 
>>>> securely authorize a transaction, can offer integrity protection on all or 
>>>> part of an HTTP request, and can provide replay protection.
>>>> 
>>>> -bill
>>>> 
>>>> From: John Bradley 
>>>> To: William Mills 
>>>> Cc: Dick Hardt ; "oauth@ietf.org" 
>>>> Sent: Thursday, August 9, 2012 11:26 AM
>>>> Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01
>>>> 
>>>> In Vancouver the question was asked about the future of the MAC spec due 
>>>> to it no linger having a editor.
>>>> 
>>>> The Chair and AD indicated a desire to have a document on the use-cases we 
>>>> are trying to address before deciding on progressing MAC or starting a new 
>>>> document.
>>>> 
>>>> Phil Hunt is going to put together a summery of the Vancouver discussion 
>>>> and we are going to work on the use-case/problem description document ASAP.
>>>> 
>>>> People are welcome to contribute to the use-case document.
>>>> 
>>>> Part of the problem with MAC has been that people could never agree on 
>>>> what it was protecting against.
>>>> 
>>>> I think there is general agreement that one or more proof mechanisms are 
>>>> required for access tokens.
>>>> Security for the token endpoint also cannot be ignored.
>>>> 
>>>> 
>>>> John B.
>>>> 
>>>> On 2012-08-09, at 1:53 PM, William Mills wrote:
>>>> 
>>>>> MAC fixes the signing problems encountered in OAuth 1.0a, yes there are 
>>>>> libraries out there for OAuth 1.0a.  MAC fits in to the OAuth 2 auth 
>>>>> model and will provide for a single codepath for sites that want to u

Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01

[Dick Hardt]

Those reasons make sense to me, thanks for enumerating.

On Aug 10, 2012, at 9:25 AM, Justin Richer wrote:

> The reason is simple: to benefit from the rest of the improvements in the 
> OAuth2 framework. These are just the ones off the top of my head:
> 
> 1) Multiple means for getting a token (all the flows are now available)
> 2) No request tokens
> 3) No reliance on per-client secrets (though, addendum, I think the MAC spec 
> should be augmented to use them if present)
> 4) Ability to integrate with many different extensions to OAuth2, both now 
> and in the future
> 
> -- Justin
> 
> On 08/10/2012 12:18 PM, Dick Hardt wrote:
>> As an implementor, I would pick a signed JWT over OAuth 1.0A. Just saying.
>> 
>> Given that, there is also a clear need for signing an HTTP(S) request as 
>> some sites are choosing OAuth 1.0A over OAuth 2.0 because they don't want to 
>> use bearer tokens.
>> 
>> I never followed what MAC solved that OAuth 1.0A did not solve. Would 
>> someone elaborate? We do have an RFC for signing requests, there are lots of 
>> libraries already. Why the desire to reinvent OAuth 1.0A?
>> 
>> -- Dick
>> 
>> On Aug 10, 2012, at 8:00 AM, Rob Richards wrote:
>> 
>>> I think you nailed it which that statement. Up until now it as been back 
>>> and forth about one or the other. Personally I prefer to used layered 
>>> security and not relying on a single point of attack. It's unrealistic to 
>>> say everyone is going to want/need/be able to use (take your pick) 
>>> signed/encrypted JWT. MAC at least offers an alternative, less complicated 
>>> solution.
>>> 
>>> Rob
>>> 
>>> On 8/10/12 10:41 AM, Richer, Justin P. wrote:
>>>> What about security in depth? Signing + TLS is more secure than either 
>>>> alone, isn't it?
>>>> 
>>>>  -- Justin
>>>> 
>>>> On Aug 10, 2012, at 3:01 AM, Hannes Tschofenig wrote:
>>>> 
>>>>> Hi Bill,
>>>>> 
>>>>> thanks for the feedback. Let's have a look at this use case:
>>>>> 
>>>>> You need to provide me a bit more information regarding your use case. 
>>>>> Could you please explain
>>>>> 
>>>>> 1) Who is authenticated to whom?
>>>>> 2) What plaintext connection are you talking about?
>>>>> 3) What is the problem with encrypted connections? Is this again the "TLS 
>>>>> has so bad performance" argument?
>>>>> 4) Since you are talking about cookies and making them more secure are 
>>>>> you trying to come up with a general solution to better cookie security - 
>>>>> a topic others are working on as well.
>>>>> 5) What is the threat you are concerned about?
>>>>> 
>>>>> Ciao
>>>>> Hannes
>>>>> 
>>>>> PS: I would heavily argue against standardize a security mechanism that 
>>>>> offers weaker protection than bearer when the entire argument has always 
>>>>> been "Bearer is so insecure and we need something stronger."
>>>>> 
>>>>> On Aug 9, 2012, at 9:43 PM, William Mills wrote:
>>>>> 
>>>>>> OK, I'll play and start documenting the use cases.
>>>>>> 
>>>>>> Use case #1: Secure authentication in plain text connections:
>>>>>> 
>>>>>> Some applications need a secure form authorization, but do not want or 
>>>>>> need the overhead of encrypted connections.  HTTP cookies and their ilk 
>>>>>> are replayable credentials and do not satisfy this need.   the MAC 
>>>>>> scheme using signed HTTP authorization credentials offer the capability 
>>>>>> to securely authorize a transaction, can offer integrity protection on 
>>>>>> all or part of an HTTP request, and can provide replay protection.
>>>>>> 
>>>>>> -bill
>>>>>> 
>>>>>> From: John Bradley 
>>>>>> To: William Mills 
>>>>>> Cc: Dick Hardt ; "oauth@ietf.org" 
>>>>>> Sent: Thursday, August 9, 2012 11:26 AM
>>>>>> Subject: Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01
>>>>>> 
>>>>>> In Vancouver the question was asked about the future of the MAC spec due 
>>>>>> to it no linger having a editor.
>>>>>&g

Re: [OAUTH-WG] mistake in draft-ietf-oauth-v2-http-mac-01

[Dick Hardt]

On Aug 10, 2012, at 9:28 AM, Justin Richer wrote:

> On 08/09/2012 06:47 PM, Dick Hardt wrote:
>> 
>> On Aug 9, 2012, at 1:08 PM, Justin Richer wrote:
>> 
>>> With MAC, you should be able to re-use about 80-90% of your existing 
>>> codepath that's in place for Bearer, simplifying the setup below. 
>> 
>> That makes no sense, I would be adding MAC to the sites that support MAC in 
>> addition to OAuth 1.0A or OAuth 2.0
> 
> You get to re-use all of the code for OAuth2 for issuing tokens (from server 
> side) and requesting tokens (from client side). Apart from parsing the JSON 
> value that's returned from the token endpoint (and you are using a generic 
> parser there, right?), nothing changes here. The part where you *use* the 
> token to access a protected resource (client), or *validate* a request to a 
> protected resource (server) changes significantly, yes. But that's only a 
> small part of the process.


That makes sense, sorry I was not clear on what I said did not make sense, 
which was "simplifying the setup below"

As a client developer, adding MAC to the mix *increases* my code base as it is 
yet another protocol to understand and implement against. OAuth 1.0A and OAuth 
2.0 bearer are not going to go away.

-- Dick___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] Fwd: [IANA #596670] Protocol Action: 'The OAuth 2.0 Authorization Framework: Bearer Token Usage' to Proposed Standard (draft-ietf-oauth-v2-bearer-23.txt)

[Dick Hardt]

Once again, would be great to have a few more eyes checking the IANA 
registrations. 

Note these are for the Bearer Token spec. 

I like that the error registry items are sorted alphabetically already. :)

Begin forwarded message:

> From: "Amanda Baber via RT" 
> Subject: [IANA #596670] Protocol Action: 'The OAuth 2.0 Authorization 
> Framework: Bearer Token Usage' to Proposed Standard 
> (draft-ietf-oauth-v2-bearer-23.txt) 
> Date: August 10, 2012 12:20:33 PM PDT
> Cc: m...@microsoft.com, dick.ha...@gmail.com, oauth-cha...@tools.ietf.org, 
> oauth-...@tools.ietf.org
> Reply-To: drafts-appro...@iana.org
> 
> Dear Authors:
> 
> ATTENTION: A RESPONSE TO THIS MESSAGE IS NEEDED 
> 
> We have completed the IANA Actions for RFC-to-be
> draft-ietf-oauth-v2-bearer-23
> 
> ACTION 1:
> 
> IANA has registered the following OAuth Access Token Type:
> 
> Name: Bearer
> Additional Endpoint Response Parameters: 
> HTTP Authentication Scheme(s): Bearer 
> Change Controller: IETF  
> Reference: [RFC-ietf-oauth-v2-bearer-23]
> 
> Please see
> http://www.iana.org/assignments/oauth-parameters
> 
> 
> ACTION 2:
> 
> IANA has registered the following in the OAuth Extensions Error Registry:
> 
> invalid_request  
> Usage Location: Resource access error response  
> Protocol Extension: Bearer access token type  
> Change Controller: IETF  
> Reference: [RFC-ietf-oauth-v2-bearer-23]
> 
> invalid_token
> Usage Location: Resource access error response  
> Protocol Extension: Bearer access token type  
> Change Controller: IETF  
> Reference: [RFC-ietf-oauth-v2-bearer-23]
> 
> insufficient_scope
> Usage Location: Resource access error response  
> Protocol Extension: Bearer access token type  
> Change Controller: IETF  
> Reference: [RFC-ietf-oauth-v2-bearer-23]
> 
> Please see
> http://www.iana.org/assignments/oauth-parameters
> 
> 
> Please let us know whether the above IANA Actions look OK. As 
> soon as we receive your confirmation, we'll notify the RFC Editor 
> that this document's IANA Actions are complete. (If this document 
> has a team of authors, one reply on behalf of everyone will suffice.)
> 
> Thanks,
> 
> Amanda Baber
> ICANN/IANA
> 

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] OAuth 1.0a

[Dick Hardt]

FYI: Google's SASL for IMAP is with OAuth 1.0A -- took me a while to get it 
working.

On Aug 14, 2012, at 12:53 PM, William Mills wrote:

> I want to get the SASL work done.   HoK is interesting, but I've become 
> convinced that it's not actually anything that needs it's own spec, you can 
> do HoK with MAC or any other signed scheme by including the needed proof of 
> ownership in the token.   HoK, however it works out, is unlikely to vary a 
> lot from the elements that would currently be needed to support MAC or 1.0a 
> and if needed can just extend the SASL mechanism.
> 
> -bill
> 
> From: Torsten Lodderstedt 
> To: William Mills  
> Cc: Mike Jones ; O Auth WG  
> Sent: Tuesday, August 14, 2012 12:42 PM
> Subject: Re: [OAUTH-WG] OAuth 1.0a
> 
> Hi Bill,
> 
> do you need to specify this aspect of your SASL profile now? Why don't you 
> wait for the group to complete the work on signing/HoK? 
> 
> You could also contribute your use cases to drive the discussion.
> 
> best regards,
> Torsten.
> 
> Am 14.08.2012 21:37, schrieb William Mills:
>> It's for the OAUTH SASL spec.  I've been writing it with the idea that OAuth 
>> 1.0a would work (since I think we'll have extant 1.0a typ[e tokens we want 
>> to allow for IMAP), but several folks were saying when this all started that 
>> 1.0a was dead and I should not refer to it.
>> 
>> I want to make sure the SASL mechanism is build to properly handle signed 
>> auth schemes and not just bearer (cookie) type.  
>> 
>> -bill
>> 
>> From: Mike Jones 
>> To: William Mills ; O Auth WG  
>> Sent: Tuesday, August 14, 2012 12:28 PM
>> Subject: RE: [OAUTH-WG] OAuth 1.0a
>> 
>> What problem are you trying to solve?
>>  
>> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of 
>> William Mills
>> Sent: Tuesday, August 14, 2012 12:22 PM
>> To: O Auth WG
>> Subject: [OAUTH-WG] OAuth 1.0a
>>  
>> What's the general opinion on 1.0a?  Am I stepping in something if I refer 
>> to it in another draft?  I want to reference an auth scheme that uses 
>> signing and now MAC is apparently going back to the drawing board, so I'm 
>> thinking about using   1.0a.
>>  
>> Thanks,
>>  
>> -bill
>> 
>> 
>> 
>> 
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
> 
> 
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Implementation Support and Community

[Dick Hardt]

+1 to StackOverflow -- that has become the goto source for programming FAQs


On Aug 23, 2012, at 7:38 AM, Justin Richer  wrote:

> With the core specs basically out the door and seeing wider adoption and 
> publicity, the OAuth community is going to start to get more questions about 
> "how do I do X?", and many of these are questions that have been answered 
> before or seem "obvious" to those of us who have been up to our ears in the 
> spec for the past few years. Nevertheless, these are important questions to 
> support for the wellbeing of the protocol community, but where should they be 
> asked?
> 
> When the OAuth community lived on a simple Google Group, these kinds of 
> questions make sense. But I'd argue that the IETF list is not really the 
> right place for them. This list, and the IETF in general, seems to be best 
> suited for *building* the protocol, not for the *use* and *support* of said 
> protocol once it's built.
> 
> The problem is that, as of right now, we don't have anywhere to point people 
> where they could get a "real" answer.
> 
> This opens a larger question of who might "sponsor" or "host" such a 
> community. Anything like that needs moderators, and more importantly, needs 
> experts willing to answer the questions. Some options I can think of:
> 
> - Revive the google groups list for these kinds of questions/discussions
> - Start a new list/forum, linked to oauth.net
> - Point everyone to StackOverflow with an "oauth" tag
> 
> 
> -- Justin (who is not volunteering himself to host or moderate the group)
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] RFC 6749 on The OAuth 2.0 Authorization Framework

[Dick Hardt]

Thanks everyone for all their work! We can now focus on the next layers in the 
identity stack.

-- Dick

On Oct 12, 2012, at 3:42 PM, rfc-edi...@rfc-editor.org wrote:

> 
> A new Request for Comments is now available in online RFC libraries.
> 
> 
>RFC 6749
> 
>Title:  The OAuth 2.0 Authorization Framework 
>Author: D. Hardt, Ed.
>Status: Standards Track
>Stream: IETF
>Date:   October 2012
>Mailbox:dick.ha...@gmail.com
>Pages:  76
>Characters: 163498
>Obsoletes:  RFC5849
> 
>I-D Tag:draft-ietf-oauth-v2-31.txt
> 
>URL:http://www.rfc-editor.org/rfc/rfc6749.txt
> 
> The OAuth 2.0 authorization framework enables a third-party
> application to obtain limited access to an HTTP service, either on
> behalf of a resource owner by orchestrating an approval interaction
> between the resource owner and the HTTP service, or by allowing the
> third-party application to obtain access on its own behalf.  This
> specification replaces and obsoletes the OAuth 1.0 protocol described
> in RFC 5849.  [STANDARDS-TRACK]
> 
> This document is a product of the Web Authorization Protocol Working Group of 
> the IETF.
> 
> This is now a Proposed Standard Protocol.
> 
> STANDARDS TRACK: This document specifies an Internet standards track
> protocol for the Internet community,and requests discussion and suggestions
> for improvements.  Please refer to the current edition of the Internet
> Official Protocol Standards (STD 1) for the standardization state and
> status of this protocol.  Distribution of this memo is unlimited.
> 
> This announcement is sent to the IETF-Announce and rfc-dist lists.
> To subscribe or unsubscribe, see
>  http://www.ietf.org/mailman/listinfo/ietf-announce
>  http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist
> 
> For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html.
> For downloading RFCs, see http://www.rfc-editor.org/rfc.html.
> 
> Requests for special distribution should be addressed to either the
> author of the RFC in question, or to rfc-edi...@rfc-editor.org.  Unless
> specifically noted otherwise on the RFC itself, all RFCs are for
> unlimited distribution.
> 
> 
> The RFC Editor Team
> Association Management Solutions, LLC
> 
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] access tokens & refresh tokens of different scopes

[Dick Hardt]

Hi Adam

Give your clarification, why not have 3 different calls to the AS so that there 
are separate refresh tokens for each RS? 

If you don't want to do that, then you will need to make the second call. I'm 
not too keen on making the protocol more complicated for an edge case.

btw: the only AS I know that uses refresh tokens in the social web is Google. 
All others have long lived access tokens IF the user granted long lived access.

-- Dick

On Oct 31, 2012, at 12:54 PM, Lewis Adam-CAL022 
 wrote:

> Hi Dick,
>  
> I guess one thing that didn’t quite come out in my first explanation is that 
> the scopes could belong to different resource servers.  So I’d rather not 
> hand RS1 an access token that can be used to access protected resources on 
> RS2 or RS3.  That is too much power for any RS to have :)
>  
> Granted if I were using a holder of key profile of OAuth (something I am also 
> very interested in) that could prevent such a thing from happening.  But even 
> with that in place, it seems ugly to send a set of scopes to an RS that only 
> supports a subset of those scopes (though I know it’s done that way today). 
>  
> I know a lot of my use cases are a bit atypical for the wg, but It still 
> seems to me to be in line with the OAuth spirit to keep the access token as 
> restricted as possible (both in terms of lifetime and in terms of scope).
>  
> adam
>  
>  
> From: Dick Hardt [mailto:dick.ha...@gmail.com] 
> Sent: Wednesday, October 31, 2012 12:19 PM
> To: Lewis Adam-CAL022
> Subject: Re: [OAUTH-WG] access tokens & refresh tokens of different scopes
>  
> If the latency is important, you can deal with the latency by making the 
> first call to the RS with the original access token while you are waiting for 
> the stricter scoped access token to come back. Once you have a stricter scope 
> access token, you can replace the original access token. 
>  
> In practice, I don't think the latency is going to be an issue, and myself, I 
> would be making a call to get a new access token just before I was going to 
> do some work since the access token is very short lived.
>  
> -- Dick
>  
> On Oct 31, 2012, at 10:00 AM, Lewis Adam-CAL022 
>  wrote:
> 
> 
> I have a use case where I would like to request both an access token and a 
> refresh token, but I would like the access token to have a scope less than 
> that of the refresh token.  It is standard OAuth behavior for using the 
> refresh token to request additional access tokens (of equal or lesser scope) 
> but the first access token that comes back always has the “master scope” of 
> the refresh token. 
>  
> For various security concerns, I always want my access tokens to be of a 
> stricter scope that the refresh token.  For example, consider the scenario of 
> a structured (JWT) access token that does not require the RS to call back to 
> the AS introspection endpoint.  Following typical OAuth guidance, it is best 
> practice to use short lived access tokens with long lived refresh tokens.  
> But I’d rather a compromised access token not compromise access to ALL my 
> resource servers.
>  
> Using the existing standard I could simply destroy the first access token 
> when it is received and then request another of lesser scope using the 
> refresh token, but now I’ve just wasted a round trip over the air, consuming 
> bandwidth and adding latency to the end user experience.
>  
> Is there anybody in the working group that feels this would be valuable?
>  
>  
> adam
>  
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] access tokens & refresh tokens of different scopes

[Dick Hardt]

On Oct 31, 2012, at 1:29 PM, Lewis Adam-CAL022 
 wrote:

> Hi Dick,
>  
> Totally agree about keeping things simple :)
>  
> I’ll be the first to admit that many of my use cases are edge cases, but I 
> was sort of hoping that “this one” might find some common mindshare within 
> the community.  Maybe it is just Google using refresh tokens today on the 
> social web, but I think we all know that OAuth is going to have life well 
> beyond the social web.  Whether that’s good or bad has of course been the 
> foundation of so much of the recent “entertainment” in the OAuth blogsphere :)

FYI: A design goal of WRAP, and hence OAuth 2.0 was to support a number of 
enterprise use cases. I expect people will use it in ways not imagined, which 
*may* require additions.

I point out the non refresh token implementations to highlight that numerous 
implementors have not felt the added security is worth the extra client 
developer overhead in case you felt that it was a requirement.

>  
> If I can’t find anybody else in the community to agree that what I propose is 
> useful, then I’ll cry uncle and let it rest.

It will be interesting to see if others have the same use case.

> Btw, in response to your question “why not have 3 different calls to the AS 
> so that there are separate refresh tokens for each RS? ” … it all comes down 
> to end user experience / latency. 

Could you not make all three calls in parallel, and then you get the access 
token that you want right away with no latency?


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] review: draft-ietf-oauth-json-web-token-05

[Dick Hardt]

On Dec 23, 2012, at 9:41 AM, =JeffH  wrote:

> 
> > Thanks for the replies, Jeff.  They make sense.  Particularly, thanks for
> > the "JSON Text Object" suggestion.
> 
> welcome, glad they made some sense.
> 
> similarly, if one employs JSON arrays, I'd define a "JSON text array".
> 
> 
> > For the "claims" definition, I'm actually prone to go with definitions based
> > on those in
> > http://openid.net/specs/openid-connect-messages-1_0-13.html#terminology -
> > specifically:
> >
> > Claim
> > A piece of information about an Entity that a Claims Provider asserts about
> > that Entity.
> > Claims Provider
> > A system or service that can return Claims about an Entity.
> > End-User
> > A human user of a system or service.
> > Entity
> > Something that has a separate and distinct existence and that can be
> > identified in context. An End-User is one example of an Entity.
> 
> well, it seems to me, given the manner in which the JWT spec is written, one 
> can make the case that JWT claims in general aren't necessarily about an 
> Entity (as the latter term is used in the context of the OpenID Connect 
> specs), rather they're in general simply assertions about something(s). this 
> is because all pre-defined JWT claim types are optional and all JWT semantics 
> are left up to specs that profile (aka re-use) the JWT spec.

Agreed. I'm using an encrypted JWT that is rendered as a QR code to store state.

-- Dick 
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] "prn" -> "sub" :: draft-ietf-oauth-json-web-token-06.txt

[Dick Hardt]

Did I miss the discussion on this code breaking change?

I'm ok with the change, but would have expected more discussion / notice about 
a change such as this.

Before I run around and make edits to running code, I'd like to know if we are 
staying with this label.

-- Dick


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] December 27, 2012 OAuth Release

[Dick Hardt]

Looks like I was not the only one that was reading "p0rn" when I saw "prn" … ;-)

On Dec 28, 2012, at 5:07 PM, Mike Jones  wrote:

> New versions of the OAuth JWT, JWT Bearer Profile, and Assertions specs have 
> been released incorporating feedback since IETF 85 in Atlanta.  The primary 
> change is changing the name of the “prn” claim to “sub” (subject) both to 
> more closely align with SAML name usage and to use a more intuitive name for 
> this concept.  (Also, see the related coordinated change to the OpenID 
> Connect specifications.)  The definition of the “aud” (audience) claim was 
> also extended to allow JWTs to have multiple audiences (a feature also in 
> SAML assertions).
>  
> An explanation was added to the JWT spec about why should be signed and then 
> encrypted.
>  
> The audience definition in the Assertions specification was relaxed so that 
> audience values can be OAuth “client_id” values.  Informative references to 
> the SAML Bearer Profile and JWT Bearer Profile specs were also added.
> This release incorporates editorial improvements suggested by Jeff Hodges, 
> Hannes Tschofenig, and Prateek Mishra in their reviews of the JWT 
> specification.  Many of these simplified the terminology usage.  See the 
> Document History section of each specification for more details about the 
> changes made.
>  
> This release is part of a coordinated release of JOSE, OAuth, and OpenID 
> Connect specifications.  You can read about the other releases here:  JOSE 
> Release Notes, OpenID Connect Release Notes.
>  
> The new specification versions are:
> ·http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-06
> ·http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-04
> ·http://tools.ietf.org/html/draft-ietf-oauth-assertions-09
>  
> HTML formatted versions are available at:
> ·http://self-issued.info/docs/draft-ietf-oauth-json-web-token-06.html
> ·http://self-issued.info/docs/draft-ietf-oauth-jwt-bearer-04.html
> ·http://self-issued.info/docs/draft-ietf-oauth-assertions-09.html
>  
> -- Mike
>  
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] OAuth2 attack surface....

[Dick Hardt]

I once again kick myself for not noticing the implicit flow was inserted into 
the spec … hopefully the warning labels keep others from supporting the 
implicit flow … but additional messaging about not supporting implicit flow 
would be useful.

I can see why Facebook wanted it for the content merging it provides, but it 
should likely have been a different API and authorization process.

On Feb 25, 2013, at 2:58 PM, "Richer, Justin P."  wrote:

> From my read, it's a combination of browser bugs (it only affects Chrome) and 
> Facebook's insistence on using the Implicit flow for everything. 
> 
> While I don't at all care for the "sky is falling" rhetoric that seems to 
> follow OAuth2, the author has some good suggestions for implementations: 
> binding redirect URIs to particular flows, preference for the code flow, not 
> using a default redirect_uri on a hosted domain with user-generated content.
> 
> But all of these are implementation issues that the OAuth2 protocol can't 
> really address directly.
> 
> -- Justin
> 
> 
> On Feb 25, 2013, at 5:42 PM, William Mills  wrote:
> 
>> 
>> 
>> DOH!!!  
>> http://homakov.blogspot.co.uk/2013/02/hacking-facebook-with-oauth2-and-chrome.html
>> 
>> From: Phil Hunt 
>> To: William Mills  
>> Sent: Monday, February 25, 2013 2:28 PM
>> Subject: Re: [OAUTH-WG] OAuth2 attack surface
>> 
>> Whats the link?
>> 
>> Phil
>> 
>> Sent from my phone.
>> 
>> On 2013-02-25, at 14:22, William Mills  wrote:
>> 
>>> I think this is worth a read, I don't have time to dive into this :(
>>> ___
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>> 
>> 
>> 
>> 
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] JWT: add "iss" and "aud" to Reserved Header Parameter Names in JWE

[Dick Hardt]

"iss" and "aud" would be optional parameters in a JWE. These parameters are in 
the payload, but since it is encrypted, the payload must be decrypted before 
they can be read. Some times knowing these parameters is required to be able to 
decrypt the payload …

These would be additions to 9.3.1 in the JWT specification.

Why "iss" is needed:

Bob and Charlie each gave Alice a KID and a symmetric key to use to verify and 
decrypt tokens from them. 

The App and Alice share keys so Alice knows it is the App.

The User authorizes Bob to give the App a token (which authorizes the App to do 
something)

The App gives the token to Alice.

Since Alice indirectly received the token,  the only way for Alice to know who 
sent the token, is to look at the KID as the "iss" claim is encrypted. If the 
"kid" values are GUIDs, then Alice can just look up the "kid" and retrieve the 
associated symmetric key, and then decrypt and verify the token and THEN see 
who sent it. If there is a collision in KID values (Bon and Charlie gave the 
same KID for different keys), then Alice will not know which symmetric key to 
use.

Why "aud" is needed:

Dave gives a KID and symmetric key to Ellen, and Frank gives a KID and 
symmetric key to Gwen. 

Ellen and Gwen trust each other and know how to talk to each other. Gwen does 
not know Dave. Ellen does not know Frank

The App and Gwen share keys so Gwen knows it is the App.

The User authorizes Dave to give the App a token

Dave gives the token to Gwen (Dave does not have a relationship with Ellen)

Gwen now has a token that Ellen can decrypt and verify, but has no method for 
knowing that Ellen can do that. The "aud" property would allow Gwen to give the 
token to Ellen to decrypt and verify.
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] JWT: add "iss" and "aud" to Reserved Header Parameter Names in JWE

[Dick Hardt]

Hi Mike

That answer makes the most sense to me as those values are often required when 
processing a payload as well, and they should be consistent. I'd be interested 
to hear any other opinions though!

-- Dick

On May 1, 2013, at 3:48 PM, Mike Jones  wrote:

> Thanks for writing this, Dick.  I think I understand your requirements and 
> why they exist.
> 
> One question you didn't answer that will come up is whether these fields must 
> also be present in the JWT claims set if they're present in the JWE header.  
> The logical answer to me seems to be something like "All claims MUST be 
> present in the JWT Claims Set; specified claims MAY also be duplicated in the 
> JWE header, and if present there, must have exactly the same values as in the 
> JWT Claims Set."
> 
> Is that the way that you imagined this working?
> 
>   -- Mike
> 
> -Original Message-
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of 
> Dick Hardt
> Sent: Wednesday, May 01, 2013 2:12 PM
> To: O Auth WG
> Subject: [OAUTH-WG] JWT: add "iss" and "aud" to Reserved Header Parameter 
> Names in JWE
> 
> "iss" and "aud" would be optional parameters in a JWE. These parameters are 
> in the payload, but since it is encrypted, the payload must be decrypted 
> before they can be read. Some times knowing these parameters is required to 
> be able to decrypt the payload ...
> 
> These would be additions to 9.3.1 in the JWT specification.
> 
> Why "iss" is needed:
> 
> Bob and Charlie each gave Alice a KID and a symmetric key to use to verify 
> and decrypt tokens from them. 
> 
> The App and Alice share keys so Alice knows it is the App.
> 
> The User authorizes Bob to give the App a token (which authorizes the App to 
> do something)
> 
> The App gives the token to Alice.
> 
> Since Alice indirectly received the token,  the only way for Alice to know 
> who sent the token, is to look at the KID as the "iss" claim is encrypted. If 
> the "kid" values are GUIDs, then Alice can just look up the "kid" and 
> retrieve the associated symmetric key, and then decrypt and verify the token 
> and THEN see who sent it. If there is a collision in KID values (Bon and 
> Charlie gave the same KID for different keys), then Alice will not know which 
> symmetric key to use.
> 
> Why "aud" is needed:
> 
> Dave gives a KID and symmetric key to Ellen, and Frank gives a KID and 
> symmetric key to Gwen. 
> 
> Ellen and Gwen trust each other and know how to talk to each other. Gwen does 
> not know Dave. Ellen does not know Frank
> 
> The App and Gwen share keys so Gwen knows it is the App.
> 
> The User authorizes Dave to give the App a token
> 
> Dave gives the token to Gwen (Dave does not have a relationship with Ellen)
> 
> Gwen now has a token that Ellen can decrypt and verify, but has no method for 
> knowing that Ellen can do that. The "aud" property would allow Gwen to give 
> the token to Ellen to decrypt and verify.
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] interim meeting in ~2 hours

[Dick Hardt]

I find the break down between authentication, authorization and delegation 
referenced in the agenda confusing. I know what each of the words mean, but not 
having been part of the early IETF OAuth conversation, I'm confused with the 
breakdown as described in the agenda.

Would it be appropriate to cover this in the agenda today, or is there a 
pointer so I can understand what we mean by these terms in the context of this 
WG?

(sorry for the last minute question, this account was not on the mail list)

-- Dick

On 2010-01-21, at 9:47 AM, Peter Saint-Andre wrote:

> Oh, and the proposed agenda is here:
> 
> http://www.ietf.org/mail-archive/web/oauth/current/msg01013.html
> 
> On 1/21/10 10:05 AM, Peter Saint-Andre wrote:
>> This is a reminder that our first interim "virtual meeting" will start
>> in a little under 2 hours. Logistical information is here:
>> 
>> http://www.ietf.org/mail-archive/web/oauth/current/msg00982.html
>> 
>> Peter
>> 
>> 
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] terminology

[Dick Hardt]

On 2010-02-02, at 2:08 PM, Peter Saint-Andre wrote:
> On 1/28/10 11:35 PM, David Recordon wrote:
>> I have a pretty strong preference of sticking with OAuth 1.0 terminology
>> as much as possible.
> 
> Agreed.

The term "server" in OAuth 1.0 does not differentiate between the Authorization 
Server and Protected Resource as are differentiated in OAuth WRAP.

The terms used in OAuth WRAP are a superset of OAuth 1.0 with changes to 
provide additional clarity.

-- Dick
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] proposed agenda for second interim meeting

[Dick Hardt]

Hi Eran

I think it is a little early in our phone discussions to get into technical 
details. The next step according to the last call was to gather and review use 
cases. Without rough consensus on what problem we are solving, your points 
below (which all do need to be discussed at some point) is just moving around 
deck chairs on the Titanic.

-- Dick

On 2010-02-02, at 11:24 PM, Eran Hammer-Lahav wrote:

> Please add:
> 
> - Discuss Adobe's recent request to allow excluding the host/port from the 
> signed message.
> 
> - With regards to #4, how should the challenge identify the token to be used 
> (realm comes free, do we need another)?
> 
> - Should a single token support multiple signature algorithms? This has 
> implications as to the information the client has to include with the request 
> (the algorithm used, etc.).
> 
> - Where should the token structure live? OAuth 1.0 includes two response 
> parameters (token and token_secret). However, since we are now moving towards 
> having the algorithm part of the token definition, as well as duration and 
> other attributes, the server will need to provide this information to the 
> client. This calls for a simple schema (can be any format but need to agree 
> to consistent names). It is currently part of the authorization/delegation 
> draft (implicitly), but we should discuss moving it to the authentication 
> draft since that's where it is used (the authorization draft simply hands 
> those "things" out).
> 
> EHL
> 
>> -Original Message-
>> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
>> Of Peter Saint-Andre
>> Sent: Tuesday, February 02, 2010 9:15 PM
>> To: OAuth WG
>> Subject: [OAUTH-WG] proposed agenda for second interim meeting
>> 
>> 
>> 
>> At the first interim meeting, we didn't get through our agenda:
>> 
>> http://www.ietf.org/mail-archive/web/oauth/current/msg01013.html
>> 
>> Therefore I propose that this time we focus on some unfinished business,
>> starting with the topic of authentication. I have reviewed all of the related
>> threads on the list and have come up with the following *rough* agenda.
>> Your feedback is welcome to improve this (a.k.a. "agenda
>> bashing") either on the list or during the meeting.
>> 
>> For logistics information, see here:
>> 
>> http://www.ietf.org/mail-archive/web/oauth/current/msg01085.html
>> 
>> **
>> 
>> AGENDA
>> 
>> Base proposal: draft-ietf-oauth-authentication-01
>> 
>> Eran had hoped to push out a new version in time for our meeting, but hasn't
>> been able to get to it yet. However, I think we can continue to move forward
>> with discussion. Feedback is welcome on the general approach, as well as
>> specific open issues.
>> 
>> Open issues
>> 
>> Issue #1: Request Signing vs. API Signing vs. Message Signing
>> http://www.ietf.org/mail-archive/web/oauth/current/msg00961.html
>> 
>> 1a. Seeming consensus for message signing.
>> 
>> 1b. No consensus yet on message format.
>>- JSON and textual key-value seem to be the leading candidates.
>> 
>> 1c. Seeming consensus for multiple/extensible signature algorithms.
>>- HMAC-SHA1
>>- HMAC-SHA256
>>- RSASSA-PKCS1-v1.5-SHA256
>>- PLAIN over SSL/TLS
>> 
>> But: which of these are Mandatory-to-Implement?
>> 
>> Issue #2: Include the Normalized Request with the Request?
>> http://www.ietf.org/mail-archive/web/oauth/current/msg00962.html
>> 
>> Seeming consensus to not include the normalized request (e.g., signature
>> string).
>> 
>> Issue #3: Allow Secrets in Cleartext, or Require Channel Encryption?
>> http://www.ietf.org/mail-archive/web/oauth/current/msg00963.html
>> 
>> Seeming consensus that channel encryption is must-implement (which does
>> not necessarily mean must-deploy).
>> 
>> Issue #4: Authentication Challenges
>> http://www.ietf.org/mail-archive/web/oauth/current/msg01039.html
>> 
>> If an authentication (access) request is unacceptable, how does the server
>> tell the client how it can provide proper credentials (e.g., by using a 
>> different
>> algorithm)?
>> 
>> Possible other topics:
>> 
>> - Mutual auth?
>>  http://www.ietf.org/mail-archive/web/oauth/current/msg00935.html
>> 
>> - Resource authorization?
>>  http://www.ietf.org/mail-archive/web/oauth/current/msg01033.html
>> 
>> **
>> 
>> /psa
>> 
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] proposed agenda for second interim meeting

[Dick Hardt]

Eran, 

Both Tony and I are explaining to you what happened on the call. If you had 
been on the call, you could have presented your view on how to proceed with the 
calls. 
While you may have a different opinion on how to proceed (which I am NOT 
arguing with), arguing with us on what happened on the call seems pointless.

-- Dick

On 2010-02-03, at 9:34 AM, Eran Hammer-Lahav wrote:

> Hi Anthony,
> 
> The problem with this approach is that it hasn't worked (multiple times) 
> before because no one ever wants to do the work of collecting and writing the 
> use cases. What we get instead are short cryptic lists and pointers to edge 
> cases. We have a good grasp on how OAuth 1.0 is used and its limitations as 
> addressed by the WRAP draft.
> 
> The best use of my time is to continue working on the drafts and asking 
> technical questions whenever a decision is needed. If and when someone writes 
> use cases, I will review those and see if they are supported by the drafts.
> 
> I will leave it up to the chairs to decide how they want to guide the working 
> group.
> 
> EHL
> 
>> -Original Message-
>> From: Anthony Nadalin [mailto:tony...@microsoft.com]
>> Sent: Wednesday, February 03, 2010 9:02 AM
>> To: Eran Hammer-Lahav; Dick Hardt
>> Cc: OAuth WG
>> Subject: RE: [OAUTH-WG] proposed agenda for second interim meeting
>> 
>> I would tend to agree with Dick based upon the last call and where that was
>> heading. I believe that Eve had some use cases to share around UMA
>> 
>> -Original Message-
>> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
>> Of Eran Hammer-Lahav
>> Sent: Wednesday, February 03, 2010 8:41 AM
>> To: Dick Hardt
>> Cc: OAuth WG
>> Subject: Re: [OAUTH-WG] proposed agenda for second interim meeting
>> 
>> Has anyone gathered and reviewed use cases? I haven't seen much of that
>> showing up on the list. From my experience, asking people for use cases
>> rarely works, unless someone is willing to do the work and collect them (and
>> so far I haven't heard from such volunteer). I much prefer the process in
>> which we produce a technical document based on OAuth 1.0 and the new
>> requirements as defined by WRAP, and discuss use cases as a property of the
>> technical attributes of this draft.
>> 
>> Of course, you don't have to agree with me, but that puts the burden of
>> producing use cases documentation on you and others interested in taking
>> that approach. We certainly have room for both, and keep in mind that my
>> token draft is not (yet) a working group item.
>> 
>> The indication I received from many of the active members of this list is 
>> that
>> we have a strong desire to show up at Anaheim with two stable drafts. I think
>> we are very close to getting the authentication piece done following much of
>> OAuth 1.0 functionality (only cleaner and better structures), as well as
>> treating bearer tokens as first class citizens. Given that no one has 
>> started a
>> discussion about the delegation flows to include, I doubt we will have a
>> stable second draft, but I plan on getting the authentication piece stable in
>> time.
>> 
>> It has also been my experience over the past two years that the biggest
>> challenge is to figure out the authentication piece. The 'go get a token' 
>> piece
>> tends to be much easier to agree on. If we get the authentication draft to a
>> stable place, my intention is to leave it there and focus on the second part
>> and come back to it as the delegation requirements become clearer (if
>> changes are needed). But at least it gives us something stable to build upon.
>> 
>> EHL
>> 
>>> -Original Message-
>>> From: Dick Hardt [mailto:dick.ha...@gmail.com]
>>> Sent: Wednesday, February 03, 2010 7:02 AM
>>> To: Eran Hammer-Lahav
>>> Cc: Peter Saint-Andre; OAuth WG
>>> Subject: Re: [OAUTH-WG] proposed agenda for second interim meeting
>>> 
>>> Hi Eran
>>> 
>>> I think it is a little early in our phone discussions to get into technical 
>>> details.
>>> The next step according to the last call was to gather and review use cases.
>>> Without rough consensus on what problem we are solving, your points
>>> below (which all do need to be discussed at some point) is just moving
>>> around deck chairs on the Titanic.
>>> 
>>> -- Dick
>>> 
>>> On 2010-02-02, at 11:24 PM, Eran Hammer-Lahav wrote:
>>> 
>>>> Please add:
>>>> 
>>&

Re: [OAUTH-WG] proposed agenda for second interim meeting

[Dick Hardt]

I recall from the call that Peter did ask if there was consensus on the 
approach of gathering use cases. There seemed consensus that the WG might not 
fully understand the problem and that this made sense. I don't see that clearly 
captured in the minutes, hence me communicating to you what had occurred on the 
call. 

FWIW: II had intended my email to be useful, non-confrontational feedback on 
your agenda proposal. I am finding your responses to be abrasive. Have I 
offended you in some way? If you have suggestions for what I can do to be more 
productive in communicating to you, I would welcome them.

-- Dick


On 2010-02-03, at 9:59 AM, Eran Hammer-Lahav wrote:

> I read the minutes.
> 
> I don't need to be on the call to present my views on how to proceed. That's 
> not how the IETF operates. I have been expressing my views for the past year, 
> right here on the list. I didn't see any consensus call from the chairs about 
> taking this approach (instead of others).
> 
> I also noticed the lack of follow up since the call with any kind of 
> discussion on use cases.
> 
> I have asked the chairs to provide a place to discuss technical issues and 
> that is what this second call is about. Unless the chairs decide to change it.
> 
> EHL
> 
>> -Original Message-
>> From: Dick Hardt [mailto:dick.ha...@gmail.com]
>> Sent: Wednesday, February 03, 2010 9:43 AM
>> To: Eran Hammer-Lahav
>> Cc: Anthony Nadalin; OAuth WG
>> Subject: Re: [OAUTH-WG] proposed agenda for second interim meeting
>> 
>> Eran,
>> 
>> Both Tony and I are explaining to you what happened on the call. If you had
>> been on the call, you could have presented your view on how to proceed
>> with the calls.
>> While you may have a different opinion on how to proceed (which I am NOT
>> arguing with), arguing with us on what happened on the call seems pointless.
>> 
>> -- Dick
>> 
>> On 2010-02-03, at 9:34 AM, Eran Hammer-Lahav wrote:
>> 
>>> Hi Anthony,
>>> 
>>> The problem with this approach is that it hasn't worked (multiple times)
>> before because no one ever wants to do the work of collecting and writing
>> the use cases. What we get instead are short cryptic lists and pointers to
>> edge cases. We have a good grasp on how OAuth 1.0 is used and its
>> limitations as addressed by the WRAP draft.
>>> 
>>> The best use of my time is to continue working on the drafts and asking
>> technical questions whenever a decision is needed. If and when someone
>> writes use cases, I will review those and see if they are supported by the
>> drafts.
>>> 
>>> I will leave it up to the chairs to decide how they want to guide the 
>>> working
>> group.
>>> 
>>> EHL
>>> 
>>>> -Original Message-
>>>> From: Anthony Nadalin [mailto:tony...@microsoft.com]
>>>> Sent: Wednesday, February 03, 2010 9:02 AM
>>>> To: Eran Hammer-Lahav; Dick Hardt
>>>> Cc: OAuth WG
>>>> Subject: RE: [OAUTH-WG] proposed agenda for second interim meeting
>>>> 
>>>> I would tend to agree with Dick based upon the last call and where
>>>> that was heading. I believe that Eve had some use cases to share
>>>> around UMA
>>>> 
>>>> -Original Message-
>>>> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On
>>>> Behalf Of Eran Hammer-Lahav
>>>> Sent: Wednesday, February 03, 2010 8:41 AM
>>>> To: Dick Hardt
>>>> Cc: OAuth WG
>>>> Subject: Re: [OAUTH-WG] proposed agenda for second interim meeting
>>>> 
>>>> Has anyone gathered and reviewed use cases? I haven't seen much of
>>>> that showing up on the list. From my experience, asking people for
>>>> use cases rarely works, unless someone is willing to do the work and
>>>> collect them (and so far I haven't heard from such volunteer). I much
>>>> prefer the process in which we produce a technical document based on
>>>> OAuth 1.0 and the new requirements as defined by WRAP, and discuss
>>>> use cases as a property of the technical attributes of this draft.
>>>> 
>>>> Of course, you don't have to agree with me, but that puts the burden
>>>> of producing use cases documentation on you and others interested in
>>>> taking that approach. We certainly have room for both, and keep in
>>>> mind that my token draft is not (yet) a working group item.
>>>> 
>>>> The indication I received fro

Re: [OAUTH-WG] proposed agenda for second interim meeting

[Dick Hardt]

On 2010-02-03, at 11:19 AM, Eran Hammer-Lahav wrote:

> I did not mean my first reply to you to be abrasive or confrontational, 
> despite being told that my work on the drafts is a waste of time ("moving 
> around deck chairs on the Titanic").

I and many others appreciate your work. That was not my intent. Wanting to 
discuss technical details when there does not seem to be consensus on the 
problem we are solving was my Titanic reference.

> 
> Any consensus call must be made on the list and not just on the call or in a 
> meeting because the list is the only place everyone is guaranteed equal 
> participation. There is nothing more important in the IETF process than 
> consensus calls and I take them very seriously.

Thanks for the clarification.
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] proposed agenda for second interim meeting

[Dick Hardt]

On 2010-02-03, at 11:21 AM, Eran Hammer-Lahav wrote:
>> -Original Message-
>> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
>> Of Eran Hammer-Lahav
>> Sent: Wednesday, February 03, 2010 11:19 AM
>> To: Dick Hardt
>> Cc: OAuth WG
>> Subject: Re: [OAUTH-WG] proposed agenda for second interim meeting
>> 
>> I did not mean my first reply to you to be abrasive or confrontational
> 
> INSERT: and I apologize if it came off that way.

Thanks. All good on my side.

-- Dick
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] proposed agenda for second interim meeting

[Dick Hardt]

On 2010-02-03, at 12:01 PM, Peter Saint-Andre wrote:

> 
> 
> On 2/3/10 12:46 PM, Dick Hardt wrote:
> 
>> Wanting to discuss technical details when there does not seem to be
>> consensus on the problem we are solving was my Titanic reference.
> 
>  Remember, these interim meetings are
> intended to air open issues and get us closer to agreement on problems,
> terminology, architecture, use cases, requirements, and possible
> technical solutions, all as a way of preparing for the in-person meeting
> in Anaheim.

That was what I thought the calls were for, which is why I did not think Eran's 
desire to add discussion of a specific technical issue was going to be well 
received. There are a number of us that are new to the WG and we likely will 
make little progress until we are all relatively on the same page on what 
problem(s) we are solving. I certainly hope we don't need to spend much time on 
these topics, but some time will be invaluable in my opinion.

Speaking for myself, I am still confused why the spec has been broken into two 
parts and what is intended in the Authentication document. I am just now 
starting to try and grok what the UMA people want to solve.

-- Dick

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] UMA use cases (was Re: proposed agenda for second interim meeting)

[Dick Hardt]

On 2010-02-03, at 10:54 AM, Eve Maler wrote:

> 
> - There is a conceptual similarity between the UMA and WRAP entities, but our 
> analysis so far shows it to be shallow in spots.  For example, WRAP's 
> "protected resource" maps fairly well to an UMA "host" (which may host any 
> number of protected resources), and WRAP's and OAuth's "client"/"consumer" 
> maps to an UMA "requester".  However, it seems that a WRAP authorization 
> server is assumed to be in the same domain as a protected resource, allowing 
> for implicit rather than explicit scoping of resources.  The UMA 
> authorization manager and any one host may be in entirely separate domains, 
> and introductions between them are intended to be user-driven.

In OAuth WRAP,  Authorization Server (AS) is NOT assumed to be in the same 
domain as the Protected Resource (PR). The Client does need to know which AS it 
can call for an Access Token for a given PR. Discovery of the PR and AS was out 
of scope for OAuth WRAP (and I think for this WG). We figured general purpose 
APIs would have their own discovery and the AS and PR would be discovered in 
that process.

-- Dick
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] proposed agenda for second interim meeting

[Dick Hardt]

On 2010-02-04, at 10:47 AM, Peter Saint-Andre wrote:

> 
> 
> On 2/3/10 11:55 AM, Dick Hardt wrote:
>> I recall from the call that Peter did ask if there was consensus on
>> the approach of gathering use cases. There seemed consensus that the
>> WG might not fully understand the problem and that this made sense.
> 
> I agree, but given that we haven't had a lot of discussion about use
> cases on the list, I figured it would be more productive to focus this
> call on the authentication work, encourage more people to contribute use
> cases over the next two weeks, and then discuss use cases on the next
> call (slated for February 11, I need to schedule that today).

Works for me. 

I'm hopeful someone can explain what is meant by "authentication work"!

>From my understanding of Eran's draft, I don't see the distinction between 
>Authorization Server and Protected Resource we have in OAuth WRAP.

-- Dick

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Which draft to use as a starting point for 'using a token'?

[Dick Hardt]

How about using draft-hardt-oauth-wrap and adding a section for how the Client 
can sign?

-- Dick

On 2010-02-04, at 11:28 PM, Eran Hammer-Lahav wrote:

> On the call today I clarified what is going on with all the different drafts. 
> In brief:
> 
> draft-hammer-oauth - documentation of the OAuth 1.0 Rev A (with changes) 
> protocol. This is done and should be approved by the IESG shortly for 
> publication.
> 
> draft-ietf-oauth-authentication - the part of OAuth 1.0 dealing with 'how to 
> use a token after you obtain it'.
> draft-ietf-oauth-web-delegation - the part of OAuth 1.0 rev A dealing with 
> 'getting a token'.
> 
> draft-hammer-http-token-auth - an alternative proposal (meant to replace 
> draft-ietf-oauth-authentication) which builds on top of OAuth 1.0 but cleans 
> up the structure and removes the client credentials when accessing protected 
> resources. It also changes how the request is normalized into a string before 
> signing.
> 
> We have three options for moving forward with 'how to use a token'. Start 
> with:
> 
> 1. draft-ietf-oauth-authentication
> 2. draft-hammer-http-token-auth
> 3. something else*
> 
> * Do not suggest something else unless you are going to submit a proposal. It 
> doesn't have to be an I-D, I am happy to do the editorial work but I will 
> need a detailed proposal that is enough to turn into a specification.
> 
> Pick.
> 
> EHL
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Signatures, Why?

[Dick Hardt]

On 2010-03-04, at 12:27 PM, Igor Faynberg wrote:

> 
> 
> Blaine Cook wrote:
>> - Why are signatures needed?
>>  
> 1) For authentication
> 
> 2) For ensuring integrity
> 
> 3) For non-repudiation

Those are the general capabilities of signatures. "Why does the Client need to 
sign the request / token?" is the full question.

Which party are we worried about authenticating? What are we trying to ensure 
the integrity of? What statement is requires non-repudiation?


>> - What do signatures need to protect?
>>  
> They protect against
> 
> 1) Fraudulent access (which, in absence of proper mechanisms, may not even 
> even be considered legally fraudulent while making considerable damage)
> 
> 2) Denial of a previous request.

I am confused by this statement. Would you elaborate?
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Recent UMA work that may inform this group's deliberations

[Dick Hardt]

Hi Eve

Looking at the WRAP oriented comments in the spec, here are some comments / 
questions:

Note
WRAP doesn't seem to say HTTPS is required for the user authorization URL; is 
this a bug in the WRAP spec? If not, is it a good idea for us to profile it in 
this way? Finally, is this the right place to say HTTPS is required for all 
these URLs?

Dick: an HTTPS requirement is prohibitive at times. See 
http://groups.google.com/group/oauth-wrap-wg/browse_thread/thread/821e73bcbd8033dd?hl=en#
 for a recent discussion on this.

Note
Need lots of examples for all of this. Also, note that WRAP forces clients to 
use POST on access token URLs and refresh token URLs; can we use GET in the way 
described here?

Dick: why do you want GET? There are security issues with using GET to the AS.

Note
Obviously this is just the highest-level sketch of what needs to happen! This 
needs to be fleshed out. (E.g., the wrap_scope format could be reused here, 
without any wildcards.)
Also, are we concerned that a malicious host could lie about the attempted 
resource and method? The only consequence seems to be "false negatives" in 
managing authorized access, in which case the user would get unhappy pretty 
quickly.

Dick: it was envisioned that the scope of a function of scope would be embedded 
in the Access Token. Or perhaps I don't understand the issue.


On 2010-03-04, at 11:01 AM, Eve Maler wrote:

> Folks may be interested to see the following experiment being performed in 
> the UMA group:
> 
> http://kantarainitiative.org/confluence/display/~xmlg...@idp.protectnetwork.org/Proposal+for+UMA+1.0+Core+Protocol
> 
> This is a proposal for a spec that uses a WRAP-friendly approach to solving 
> our use cases.  Please note the final comments in today's UMA telecon minutes 
> for cautions about additional requirements we have:
> 
> http://kantarainitiative.org/confluence/display/uma/UMA+telecon+2010-03-04
> 
>   Eve
> 
> Eve Maler
> e...@xmlgrrl.com
> http://www.xmlgrrl.com/blog
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Recent UMA work that may inform this group's deliberations

[Dick Hardt]

Thanks Eve, comments inserted ... 

On 2010-03-04, at 12:51 PM, Eve Maler wrote:

> As requested on today's call, here's a description of the places where UMA 
> seems to need "more" than what the WRAP paradigm offers (both profiling and 
> extending), based on the proposal at:
> 
> http://kantarainitiative.org/confluence/display/~xmlg...@idp.protectnetwork.org/Proposal+for+UMA+1.0+Core+Protocol
> 
> Cautions in reading this note:
> 
> - The mix of likely needed profiles and extensions for our use of the OAuth 
> 1.0 paradigm (the existing spec on the UMA site) is quite different from the 
> list presented here, and in addition, that spec wasn't written with a goal to 
> highlight such items the way this proposal was.
> 
> - The proposal is currently fairly high-level, and other profiling/extension 
> needs may come to light if we proceed down this path -- or some of the needs 
> may disappear.  The proposal nonetheless tries to document profile and 
> extension points as precisely as possible.
> 
> - UMA's terminology is similar but not identical to WRAP's.  The proposal 
> tries to be as clear as possible about the distinctions, but caveat lector.
> 
> - For all of the profile/extension items listed, they may be of interest only 
> to UMAnitarians, or they might have wider application as optional or required 
> portions of a core OAuth 2.0 spec.  We're not trying to prejudice this 
> outcome, just provide useful information for making the decision in the wider 
> community.
> 
> So, with all that said...  Here is the conception of UMA's use of the WRAP 
> paradigm as conceived in the proposal.
> 
> 1. Currently, WRAP says nothing about how a Protected Resource and an 
> Authorization Server "meet" and figure out how to work together.

This was explicitly out of scope for WRAP. There are scale and privacy 
advantages to the PR and AR not meeting. The PR needs to trust the AR the 
issued the Access Token (and of course be able to verify the Access Token was 
issued by the AR), but the AR does NOT need to be aware of the PR. In this way, 
WRAP 

>  UMA has reason to make the user's choice of authorization management (AM) 
> services and hosts of their resources be dynamic and flexible -- that's why 
> it's called "user-managed access" -- so the proposal suggests a special way 
> to use (an embedded instance of one of the user delegation profiles of) WRAP 
> to introduce them, as a "step 1".  (The token thus acquired by the host in 
> this step plays a role in "step 3".)

Interesting use of WRAP. I don't see a hole in WRAP for you to do this. Is 
there some functionality missing?

> 
> 2a. Another of UMA's goals is to allow authorizing users (roughly, Resource 
> Owners) to make demands of other parties before granting them access rather 
> than just permissioning the connection "silently".  The mechanism for making 
> these demands is to require the requesting side to provide claims (yes, in 
> the identity claims sense) and even to make this process have legal 
> enforceability consequences where possible.  Thus, the proposal suggests an 
> extended getting-a-token phase in a "step 2" that adds a new third option to 
> the two usual WRAP options (successful access token response and unsuccessful 
> access token response): a claims-required response.

I can see it being useful in a standard return parameter that can contain an 
value undefined by WRAP (similar to the scope parameter), that is used by the 
AS to communicate to the Client what else the Client needs to be granted an 
Access Token. Is this what you are asking for?

> 
> 2b. Due to our analysis of the legal (cough) and UX dimensions of the UMA 
> proposition, we've discovered that it's useful to separate requesting parties 
> (the legally responsible party "behind" the requester/Client) into legal 
> persons vs. natural persons.  This is a way in which UMA deviates from OAuth 
> and WRAP entirely, in that we're figuring out how to do "person-to-person 
> sharing" (Alice permissions Bob to subscribe to a hosted calendar of hers) 
> along with "person-to-service sharing" (Alice permissions ECommerce.com to 
> grab her current shipping address from her personal datastore).  The current 
> thinking is that it's a matter of putting the requester into a user-delegated 
> flow vs. an autonomous-client flow as part of getting a token in step 2.

Is there something missing in WRAP to do this?

> 
> 2c. Currently, WRAP doesn't say anything about how to fill the scope 
> parameter value.  In this context, an obvious optimization is the "all the 
> photos that happen to be in this folder" authorization scenario.  So we went 
> ahead and proposed a simple JSON-based format for describing both simple 
> access scope and basic wildcarded access scope.

Different scenarios will require different scope values. We thought it useful 
to define the parameter so that it would  be easier library providers and specs 
like UMA to define the value without also having to

Re: [OAUTH-WG] Anaheim agenda, v0.1

[Dick Hardt]

I could have some commentary on the mixed approach as well.

I've been contemplating extending the WRAP draft to include signatures once the 
requirements / capabilities of signatures was clear.

-- Dick

On 2010-03-04, at 4:48 PM, David Recordon wrote:

> Cool.  Happy to share my intro time with Eran/Chris/Blain if they'd
> like as well.
> 
> On Thu, Mar 4, 2010 at 2:29 PM, Peter Saint-Andre  wrote:
>> 
>> 
>> Based on our discussion in the conference call earlier today, here is a
>> rough agenda for our 2-hour session in Anaheim.
>> 
>> ***
>> 
>> 0. Administrivia (chairs, 5 mins)
>> 
>> 1. OAuth intro (David Recordon, 15 mins)
>> 
>> 2. WRAP (Dick Hardt, 15 mins)
>> 
>> 3. Mixed approach (Eran Hammer-Lahav / David Recordon, 25 mins)
>> 
>> 4. Open issues with mixed approach (moderated discussion, 45 mins)
>> 
>> 5. Use cases / scenarios as WG item (5 mins)
>> 
>> 6. Summary / action items (10 mins)
>> 
>> ***
>> 
>> Bash away!
>> 
>> Peter
>> 
>> --
>> Peter Saint-Andre
>> https://stpeter.im/
>> 
>> 
>> 
>> 
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>> 
>> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] [WRAP] Username and Password Profile

[Dick Hardt]

As was discussed on the OAuth list, desktop apps can NOT be secured, so there 
is no way to ensure it really is the desktop app you think it is. For most 
phone platforms, this is also the case. For totally locked platforms where the 
app is part of the OS (xbox, PS3, some phones, settop boxes) -- then one can 
have high confidence the app is the app. So far I consider these the exception 
rather than the rule.

-- Dick

On 2010-03-04, at 8:37 PM, David Recordon wrote:

> +ietf list
> 
> 
> On Mar 4, 2010, at 8:16 PM, Jason Hullinger  wrote:
> 
>> I think there are probably going to be more instances of providers needing 
>> this than otherwise. The current Username and Password profile is not a 
>> solution in a for every sense, and there clearly is a need for a secure 
>> protocol where you can validate that the client is who they say they are in 
>> a profile such as on a phone or desktop application.
>> 
>> ~/Jason Hullinger
>> 
>> On Thu, Mar 4, 2010 at 7:30 PM, Luke Shepard  wrote:
>> Is Facebook the only one who needs this?
>> 
>> Sent from my iPhone
>> 
>> On Mar 4, 2010, at 6:41 PM, "Dick Hardt"  wrote:
>> 
>>> The spec allows the AS to define additional parameters, so for these 
>>> specialized use cases, Facebook could ask Microsoft and Sony to include an 
>>> identifier in the request.
>>> 
>>> Is that adequate?
>>> 
>>> On Thu, Mar 4, 2010 at 6:28 PM, David Recordon  wrote:
>>> Devices such as an XBox or PS3 can keep secrets which is primarily
>>> where we envision using the username/password profile.
>>> 
>>> On Thu, Mar 4, 2010 at 5:52 PM, Dick Hardt  wrote:
>>> >
>>> > On 2010-03-04, at 3:58 PM, Luke Shepard wrote:
>>> >
>>> >> On Mar 4, 2010, at 3:42 PM, Marius Scurtescu wrote:
>>> >>
>>> >>> On Thu, Mar 4, 2010 at 11:58 AM, Jason Hullinger  
>>> >>> wrote:
>>> >>>>
>>> >>>> wrap_client_id - Required. The client identifier
>>> >>>> wrap_username - Required. The User’s username
>>> >>>> wrap_password - Required. The User’s password
>>> >>>> wrap_scope - Optional. Authorization scope values defined by the server
>>> >>>> Additional parameters - Any additional parameter defined by the
>>> >>>> authorization server
>>> >>>>
>>> >>>> From the above parameters there is no way of insuring that a client is 
>>> >>>> ever
>>> >>>> who they say they are because a user could easily obtain the 
>>> >>>> wrap_client_id
>>> >>>> and make requests using that. Does anyone have an implementation of 
>>> >>>> this or
>>> >>>> any recommended additional parameters?
>>> >>>
>>> >>> I don't think you need to trust this client itself in any way, the
>>> >>> user trusted the client and provided his/her username and password,
>>> >>> that's all that counts. The should just verify these credentials and
>>> >>> then issue refresh and access tokens.
>>> >>
>>> >> It's pretty important to Facebook that we be able to validate who the 
>>> >> client is when they pass in user credentials. We have pretty strict 
>>> >> restrictions on the ability for apps to take user credentials directly 
>>> >> and we need to be able to enforce those restrictions. I would like to 
>>> >> see the ability to authenticate the app as well in this profile.
>>> >
>>> > This profile was motivated by the use case of rich clients where 
>>> > redirection of a browser is challenging. ie. a twitter app on a phone.
>>> >
>>> > Per previous discussions in OAuth, it is not feasible with current 
>>> > platforms for an app running on a user machine to keep secrets from 
>>> > malicious users. A web app of course can keep a secret from the user, but 
>>> > use of this profile by a web app does not seem to make sense.
>>> >
>>> > -- Dick
>>> >
>>> >
>>> >
>>> > --
>>> > You received this message because you are subscribed to the Google Groups 
>>> > "OAuth WRAP WG" group.
>>> > To post to this group, send email to oauth-wrap...@googlegroups.com.
>>> > To unsubscribe from this group, send email to 
>>> > o

Re: [OAUTH-WG] Signatures, Why?

[Dick Hardt]

On 2010-03-04, at 9:31 PM, Igor Faynberg wrote:

> 
> 
> Dick Hardt wrote:
>> On 2010-03-04, at 12:27 PM, Igor Faynberg wrote:
>> ...
>>>> - Why are signatures needed?
>>>>   
>>> 1) For authentication
>>> 
>>> 2) For ensuring integrity
>>> 
>>> 3) For non-repudiation
>>>
>> 
>> Those are the general capabilities of signatures. "Why does the Client need 
>> to sign the request / token?" is the full question.
>>  
> 
> Yes, these are the benefits of using signatures. As Brian has already 
> pointed, there have been cases on the record. I tried to summarize the 
> benefits in a short answer, but I don't mind elaborating.
>> Which party are we worried about authenticating?   
> 
> The Client, of course. And it is not simply that we are authenticating the 
> Client, we a) authenticate the token and b) ensure that it has not been 
> modified. Say, a rogue Client through some sort of phishing pretends to the 
> end user to be legitimate in accessing the user's data and--to the server 
> (i.e., service provider) it pretends to be a legitimate partner. A lot of bad 
> things may happen. Yet, if the request for *temporary credentials* is denied 
> when the signature is  verified and found wrong, nothing would proceed. Here, 
> only a legitimate client can even start a transaction.

What makes a client legitamate? In a rich application, all Client secrets can 
be discovered.

> 
> And then, later the request for *token credentials* also needs to be signed 
> (and differently) to ensure   that of all the legitimate Clients only the 
> Client authorized by the end user can access the record.
> 
>> What are we trying to ensure the integrity of?
> 
> The request, of course. Incidentally, this feature would come "for free" 
> anyway if the client signs the hash of the request and sends it along with 
> the request itself. (And throwing in a nonce into the hash would prevent 
> replay.)

Throwing in a nonce also introduces a requirement to the PR to maintain state.

...

So far, you are explaining security 101. 

If there is a secure channel between the Client and the PR, and the token is 
only accepted at one Client. What other advantages are there to the Client 
signing that you don't get from a bearer token?

-- Dick
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] [WRAP] Username and Password Profile

[Dick Hardt]

You are correct. If a AS, supports the username and password profile, that 
means it can be used by any client. Clearly the user has made a trust decision 
about the client in this case, assuming there really is a user running the 
client.

One option for a provider to minimize their exposure is they may not issue 
Access Tokens that have as much power to Clients using the Username and 
Password profile.

This is a good point to call out in the currently un-written security 
considerations.

-- Dick

On 2010-03-05, at 12:17 AM, Jason Hullinger wrote:

> If it's impossible to validate who a client is for even one particular 
> protocol in the spec, doesn't this leave a provider's web service open to 
> anyone making an authentication/login request to that implemented profile in 
> the spec? Unless I'm missing something, this is a problem because a provider 
> would be opening themselves up to likely phishing attacks, and no way to stop 
> it except by shutting down the entire protocol that allowed it. Perhaps this 
> is just a documentation issue because implementing this portion of the spec 
> could potentially make a provider less secure with no real way of stopping it 
> after it's implemented.
> 
> ~/Jason Hullinger
> 
> On Thu, Mar 4, 2010 at 9:37 PM, Dick Hardt  wrote:
> As was discussed on the OAuth list, desktop apps can NOT be secured, so there 
> is no way to ensure it really is the desktop app you think it is. For most 
> phone platforms, this is also the case. For totally locked platforms where 
> the app is part of the OS (xbox, PS3, some phones, settop boxes) -- then one 
> can have high confidence the app is the app. So far I consider these the 
> exception rather than the rule.
> 
> -- Dick
> 
> 
> On 2010-03-04, at 8:37 PM, David Recordon wrote:
> 
>> +ietf list
>> 
>> 
>> On Mar 4, 2010, at 8:16 PM, Jason Hullinger  wrote:
>> 
>>> I think there are probably going to be more instances of providers needing 
>>> this than otherwise. The current Username and Password profile is not a 
>>> solution in a for every sense, and there clearly is a need for a secure 
>>> protocol where you can validate that the client is who they say they are in 
>>> a profile such as on a phone or desktop application.
>>> 
>>> ~/Jason Hullinger
>>> 
>>> On Thu, Mar 4, 2010 at 7:30 PM, Luke Shepard  wrote:
>>> Is Facebook the only one who needs this?
>>> 
>>> Sent from my iPhone
>>> 
>>> On Mar 4, 2010, at 6:41 PM, "Dick Hardt"  wrote:
>>> 
>>>> The spec allows the AS to define additional parameters, so for these 
>>>> specialized use cases, Facebook could ask Microsoft and Sony to include an 
>>>> identifier in the request.
>>>> 
>>>> Is that adequate?
>>>> 
>>>> On Thu, Mar 4, 2010 at 6:28 PM, David Recordon  wrote:
>>>> Devices such as an XBox or PS3 can keep secrets which is primarily
>>>> where we envision using the username/password profile.
>>>> 
>>>> On Thu, Mar 4, 2010 at 5:52 PM, Dick Hardt  wrote:
>>>> >
>>>> > On 2010-03-04, at 3:58 PM, Luke Shepard wrote:
>>>> >
>>>> >> On Mar 4, 2010, at 3:42 PM, Marius Scurtescu wrote:
>>>> >>
>>>> >>> On Thu, Mar 4, 2010 at 11:58 AM, Jason Hullinger  
>>>> >>> wrote:
>>>> >>>>
>>>> >>>> wrap_client_id - Required. The client identifier
>>>> >>>> wrap_username - Required. The User’s username
>>>> >>>> wrap_password - Required. The User’s password
>>>> >>>> wrap_scope - Optional. Authorization scope values defined by the 
>>>> >>>> server
>>>> >>>> Additional parameters - Any additional parameter defined by the
>>>> >>>> authorization server
>>>> >>>>
>>>> >>>> From the above parameters there is no way of insuring that a client 
>>>> >>>> is ever
>>>> >>>> who they say they are because a user could easily obtain the 
>>>> >>>> wrap_client_id
>>>> >>>> and make requests using that. Does anyone have an implementation of 
>>>> >>>> this or
>>>> >>>> any recommended additional parameters?
>>>> >>>
>>>> >>> I don't think you need to trust this client itself in any way, the
>>>> >>> user trusted the client

Re: [OAUTH-WG] Signatures, Why?

[Dick Hardt]

On 2010-03-07, at 12:13 PM, Ethan Jewett wrote:

> My point is only that bearer-tokens over an insecure channel seem to
> be always *less* secure or *as* secure (but never *more* secure) than
> using a signature approach over an insecure channel. As such, I'm
> uncomfortable taking away an existing, widely implemented, and usually
> more secure approach for authentication over an insecure channel
> (OAuth 1.0a signing) and replacing it with a less secure approach
> (bearer tokens w/o SSL/TLS).


This prompts me to argue that allowing signatures is worse than bearer tokens. 
(I'm adding to the conversation here, I don't consider myself a security expert)


1) The server needs to manage state for the nonces, and properly implement 
nonce management. This added complexity can lead to additional security holes 
in the server. I'd be curious on what penetration testing has been done on 
existing OAuth deployments.

2) Client signed tokens are no more secure in MITM attacks than bearer tokens 
for on-the-fly attacks. If the attacker can disrupt the channel, the attacker 
can take the signed token and use it to make a valid call just as if it was a 
bearer token. Imagine the attacker disrupting every other request, and using 
the valid token to make an API call. The Client does not know an attack is 
going on it thinks it is having to repeat every other call, and the Server 
likely thinks the connection is flaky.

3) Deployments are made assuming there is more security than bearer tokens. 
People deploy OAuth in situations where they would not deploy a bearer token 
architecture because they think the signatures prevent attacks.

-- Dick
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Signatures, Why?

[Dick Hardt]

On 2010-03-08, at 1:09 PM, John Kemp wrote:

> 
> On Mar 8, 2010, at 3:35 PM, Dick Hardt wrote:
>> 
>> 
>> 2) Client signed tokens are no more secure in MITM attacks than bearer 
>> tokens for on-the-fly attacks. If the attacker can disrupt the channel, the 
>> attacker can take the signed token and use it to make a valid call just as 
>> if it was a bearer token. Imagine the attacker disrupting every other 
>> request, and using the valid token to make an API call. 
> 
> I think that what you mean here is that the MITM steals (at least the signed 
> portion of) the request as well as the token. 

yes

> 
> If the MITM has to sign a request it created itself, even with a stolen 
> token, it will (or should) not have access to the secret key assigned to a 
> properly-provisioned client, and thus cannot authenticate correctly to the 
> recipient.

correct
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Recent UMA work that may inform this group's deliberations

[Dick Hardt]

On 2010-03-05, at 6:57 AM, Eve Maler wrote:

> More below...
> 
> On 4 Mar 2010, at 5:43 PM, Dick Hardt wrote:
> 
>> Thanks Eve, comments inserted ... 
>> 
>> On 2010-03-04, at 12:51 PM, Eve Maler wrote:
>> 
>>> As requested on today's call, here's a description of the places where UMA 
>>> seems to need "more" than what the WRAP paradigm offers (both profiling and 
>>> extending), based on the proposal at:
>>> 
>>> http://kantarainitiative.org/confluence/display/~xmlg...@idp.protectnetwork.org/Proposal+for+UMA+1.0+Core+Protocol
>>> 
>>> Cautions in reading this note:
>>> 
>>> - The mix of likely needed profiles and extensions for our use of the OAuth 
>>> 1.0 paradigm (the existing spec on the UMA site) is quite different from 
>>> the list presented here, and in addition, that spec wasn't written with a 
>>> goal to highlight such items the way this proposal was.
>>> 
>>> - The proposal is currently fairly high-level, and other 
>>> profiling/extension needs may come to light if we proceed down this path -- 
>>> or some of the needs may disappear.  The proposal nonetheless tries to 
>>> document profile and extension points as precisely as possible.
>>> 
>>> - UMA's terminology is similar but not identical to WRAP's.  The proposal 
>>> tries to be as clear as possible about the distinctions, but caveat lector.
>>> 
>>> - For all of the profile/extension items listed, they may be of interest 
>>> only to UMAnitarians, or they might have wider application as optional or 
>>> required portions of a core OAuth 2.0 spec.  We're not trying to prejudice 
>>> this outcome, just provide useful information for making the decision in 
>>> the wider community.
>>> 
>>> So, with all that said...  Here is the conception of UMA's use of the WRAP 
>>> paradigm as conceived in the proposal.
>>> 
>>> 1. Currently, WRAP says nothing about how a Protected Resource and an 
>>> Authorization Server "meet" and figure out how to work together.
>> 
>> This was explicitly out of scope for WRAP. There are scale and privacy 
>> advantages to the PR and AR not meeting. The PR needs to trust the AR the 
>> issued the Access Token (and of course be able to verify the Access Token 
>> was issued by the AR), but the AR does NOT need to be aware of the PR. In 
>> this way, WRAP 
> 
> (Unfinished sentence?)

D'oh ... In this way WRAP is a claims based model.

> 
> As noted above, it's fine for this to be out of scope for WRAP itself, but 
> it's in UMA's scope.


> 
>> 
>>> UMA has reason to make the user's choice of authorization management (AM) 
>>> services and hosts of their resources be dynamic and flexible -- that's why 
>>> it's called "user-managed access" -- so the proposal suggests a special way 
>>> to use (an embedded instance of one of the user delegation profiles of) 
>>> WRAP to introduce them, as a "step 1".  (The token thus acquired by the 
>>> host in this step plays a role in "step 3".)
>> 
>> Interesting use of WRAP. I don't see a hole in WRAP for you to do this. Is 
>> there some functionality missing?
> 
> I don't understand the comment/question.  Are you suggesting the WRAP pattern 
> (same as the three-legged OAuth pattern, which our current spec uses) can't 
> be applied to new use cases?  It's pretty much a vanilla application of the 
> pattern.  If it's not interesting as a generic solution and the problem space 
> is only UMA's, that's certainly okay with us.
> 

I have no issue with WRAP being used in this way. I have not seen the pattern 
before. Perhaps once UMA is well known, others will want to use the same 
pattern and we can standardize it.

>> 
>>> 
>>> 2a. Another of UMA's goals is to allow authorizing users (roughly, Resource 
>>> Owners) to make demands of other parties before granting them access rather 
>>> than just permissioning the connection "silently".  The mechanism for 
>>> making these demands is to require the requesting side to provide claims 
>>> (yes, in the identity claims sense) and even to make this process have 
>>> legal enforceability consequences where possible.  Thus, the proposal 
>>> suggests an extended getting-a-token phase in a "step 2" that adds a new 
>>> third option to the two usual WRAP options (successful access token 
>>> re

Re: [OAUTH-WG] Signatures, Why?

[Dick Hardt]

On 2010-03-08, at 6:39 PM, Ethan Jewett wrote:

> Request hijacking: I actually significantly understated the protection
> against request hijacking that that the HMAC-SHA1 method of OAuth 1.0a
> provides. In the worst case, a MITM can hijack a request but cannot
> change the request method, URL, query parameters, nonce, or timestamp.
> In the best case (a single-part form-encoded request body or a request
> consisting only of query parameters), the MITM cannot modify the
> request at all because it is fully signed. It is not true, as Dick
> contends, that a MITM who has captured a signed OAuth 1.0a request can
> use a signed access token as if it were a bearer token. It is far more
> limited in the worst case, and useless in the best case.

After reviewing the 3.4 of draft-hammer-oauth I see that the query string is 
part of the string being signed, minimizing the attack surface. Thanks for 
pointing out my misunderstanding.

-- Dick


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Recent UMA work that may inform this group's deliberations

[Dick Hardt]

On 2010-03-09, at 7:05 AM, Eve Maler wrote:
> 
> It's a good idea to give guidance on how the scope parameter should be used.  
> That way, it will help avoid "abuse" of the parameter for other purposes, and 
> clashes if different deployments are using it in different ways.  (I suspect 
> that the tradeoff here is making it (superficially?) appealing for 
> implementers vs. making it more interoperable for deployers.)

Thanks. Will add to list of edits.

> Right, the Client doesn't do this processing.  However, if the point of 
> making tokens opaque to "the Client" is to save them trouble, I wanted to 
> point out that some of our use cases have the same overall application 
> deploying a Client along with also being a Protected Resource, and that it 
> could be reasonable to want to save such an app as much trouble as possible 
> in the aggregate.  WRAP today assumes that "the Protected Resource" validates 
> a signature locally.  However, this could be expensive (in the sense of 
> requiring PKI infrastructure).  Another option is to have it offload 
> validation to the Authorization Server as a back-channel operation, which has 
> its own pros and cons.  For now, in UMA we're thinking of defining the 
> back-channel loop as an extension (which could be completely opaque to the 
> core protocol underneath).

Understood. We could add to the spec that the validation could happen at a 
service instead of locally.

-- Dick

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Defining a maximum token length?

[Dick Hardt]

On 2010-03-09, at 4:23 PM, Marius Scurtescu wrote:

> On Tue, Mar 9, 2010 at 3:50 PM, David Recordon  wrote:
>> Ideally we'd limit the length of access and refresh tokens as well as
>> client keys and secrets to no more than 255 characters (a one byte
>> varchar in MySQL).
> 
>>  Is this an issue for anyone?
> 
> That being said, I don't see a problem with limiting the lengths.

I would not want to limit them anymore than they need to be.
When editing OAuth WRAP, we looked into size issues. Current limits are HTTP 
header size limitations, which are 4-8K total.

Given the ability to put all the claims needed into the Access Token, I can see 
Access Tokens being 1-2K and being really useful.

-- Dick
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Defining a maximum token length?

[Dick Hardt]

On 2010-03-09, at 6:24 PM, Ethan Jewett wrote:

> I think it would make sense to advise client library and application
> programmers to provide for the possibility of and storage of large
> tokens. We should probably reference examples of tokens seen in the
> wild and mention the technical limitations on token length from the
> HTTP protocol (with Dick outlines). I'm not sure where in the spec
> this would go, but it sounds like a good thing to include.

In the WRAP spec, we had a section entitled "Parameter Considerations".

-- Dick
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Defining a maximum token length?

[Dick Hardt]

I understand the desire to set a max length that can easily fit into a DB.
There are lots of other items I think the developer is storing that can be
long as well, like URLs -- so I don't see it as a huge issue.

I do see the need to make it clear that it can be a few K or something like
that so that people don't assume it is shorter than it might be.

-- Dick

On Tue, Mar 9, 2010 at 7:16 PM, David Recordon  wrote:

> The challenge is that client developers (who we really want to make
> OAuth dead simple for) will be forced to use less optimal storage for
> tokens (blobs versus shorter and indexable types such as varchars).
> They also won't be able to build any assumptions around token length
> into their database design.  Any DBA cringes when they see the blob
> type for multiple columns within a table (access token and refresh
> token per user).
>
> Some OAuth servers will have short tokens which a client might
> integrate with first and decide that a varchar(255) is reasonable to
> hold tokens.  They'll then run across a server with longer tokens, not
> realize it, and be confused why their client isn't working when it's
> due to their database silently truncating tokens after 255 characters.
>
> --David
>
> On Tue, Mar 9, 2010 at 6:24 PM, Ethan Jewett  wrote:
> > Agreed. I've heard tell of Yahoo access tokens with encoded
> > information weighing in at up to 800 characters. I don't see anything
> > necessarily wrong with this and I don't think there's much reason to
> > limit it in the spec. It could incur a significant bandwidth cost, but
> > since the provider is going to shoulder most of this cost the provider
> > in a good position to make the tradeoff calculation.
> >
> > I think it would make sense to advise client library and application
> > programmers to provide for the possibility of and storage of large
> > tokens. We should probably reference examples of tokens seen in the
> > wild and mention the technical limitations on token length from the
> > HTTP protocol (with Dick outlines). I'm not sure where in the spec
> > this would go, but it sounds like a good thing to include.
> >
> > Ethan
> >
> > On Tue, Mar 9, 2010 at 8:14 PM, Dick Hardt  wrote:
> >>
> >> On 2010-03-09, at 4:23 PM, Marius Scurtescu wrote:
> >>
> >>> On Tue, Mar 9, 2010 at 3:50 PM, David Recordon 
> wrote:
> >>>> Ideally we'd limit the length of access and refresh tokens as well as
> >>>> client keys and secrets to no more than 255 characters (a one byte
> >>>> varchar in MySQL).
> >>>
> >>>>  Is this an issue for anyone?
> >>>
> >>> That being said, I don't see a problem with limiting the lengths.
> >>
> >> I would not want to limit them anymore than they need to be.
> >> When editing OAuth WRAP, we looked into size issues. Current limits are
> HTTP header size limitations, which are 4-8K total.
> >>
> >> Given the ability to put all the claims needed into the Access Token, I
> can see Access Tokens being 1-2K and being really useful.
> >>
> >> -- Dick
> >> ___
> >> OAuth mailing list
> >> OAuth@ietf.org
> >> https://www.ietf.org/mailman/listinfo/oauth
> >>
> > ___
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
> >
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Defining a maximum token length?

[Dick Hardt]

On 2010-03-09, at 7:50 PM, David Recordon wrote:

> On Tue, Mar 9, 2010 at 7:25 PM, Dick Hardt  wrote:
>> I understand the desire to set a max length that can easily fit into a DB.
>> There are lots of other items I think the developer is storing that can be
>> long as well, like URLs -- so I don't see it as a huge issue.
>> I do see the need to make it clear that it can be a few K or something like
>> that so that people don't assume it is shorter than it might be.
>> -- Dick
> 
> Why would the URLs be stored in a database?  

Same reason an Access Token would be. Was that a trick question?
My point was that there are other arbitrary pieces of data that developers 
store and need to retrieve.

> Wouldn't they be in
> configuration files given that OAuth doesn't support discovery of new
> servers?

yet

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] [WRAP] Username and Password Profile

[Dick Hardt]

+1

On 2010-03-10, at 8:51 AM, Allen Tom wrote:

> +1
> 
> I'd like to keep the existing username/password profile as it currently is,
> with the understanding that Service Providers may add additional proprietary
> parameters and secret sauce to authenticate the client.
> 
> Allen
> 
> 
> On 3/9/10 9:32 PM, "Brian Eaton"  wrote:
> 
>> On Tue, Mar 9, 2010 at 12:02 PM, David Recordon  wrote:
>>> I'd rather support the client secret and document the hell out of the
>>> security considerations for the profile.
>> 
>> Thinking out loud... what if we called it the "server you trust to use
>> username and password profile" instead of the client app profile?
>> 
>> That would actually meet the xbox use case, as follows:
>> 
>> 1) Microsoft uses magic security sauce to authenticate the xbox to
>> their servers.
>>This magic security sauce will be obscure, will probably change
>> frequently, and is probably going to rely on hardware security
>> modules.  It makes no sense to standardize this, because the goal is
>> specifically to avoid interoperable implementations. =)
>> 
>> 2) Their servers hold the client secret, and use it to authenticate to
>> whatever service they are using for password validation.
>>Note that they can actually change this secret, because it is
>> stored server-side.
>> 
>> I'm sure that people are going to run off and use this profile to
>> hard-code secrets in their iphone apps, and if the secrets are
>> important they will be reverse-engineered and abused.  But that's what
>> happens when you take a profile intended for one kind of deployment
>> environment and use it in a very, very different environment.
>> 
>> (Also note that the user experience/completion rate for the
>> browser-redirect flows on thick clients can actually be pretty good.
>> We've done usability studies, and it works:
>> http://sites.google.com/site/oauthgoog/UXFedLogin/desktopapps.  For
>> trusted partners you can customize the login and approval screen as
>> well.)
>> 
>> Cheers,
>> Brian
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Signatures, Why?

[Dick Hardt]

On 2010-03-12, at 10:22 AM, Eve Maler wrote:

> This nets out to the requesting party (person or company seeking access) 
> having an incentive to say "It's really me accessing this", such that it 
> mitigates the risk that the requester (client) will hand off both the access 
> token and the signing secret to a third party.


Note I am NOT a security expert, and would appreciate an education on where I 
am wrong.

When I look at this, I question if there really is that much more value in the 
Client having two secret items over one secret item. 

I can see an advantage with something like using RAS, in that only the Client 
should have the private key, and if the private key can be used for lots of 
things, then there is some difference between a token and the private key. With 
symmetric keys, multiple parties have the keys, so non-repudiation is not 
possible.

-- Dick___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Signatures, Why?

[Dick Hardt]

Hi Igor

Thanks for explanation. Unfortunately I am more  confused. How does the third 
party know who the Client is?

I don't understand how an Access Token plus a signing secret gives any more 
assurance than an Access Token unless I get the Access Token from a different 
place than the signing secret. Is that what I am missing?

-- Dick

On 2010-03-12, at 11:38 AM, Igor Faynberg wrote:

> Dick,
> 
> The trick here is THE THIRD PARTY (referred to in the last words of Eve's 
> message), who is effectively a witness to the transaction. (This works pretty 
> much like when you want to switch your telephone provider. You would be 
> transferred to the third party to confirm your request.) Absent of the 
> private-key signature, this is the only known way to ensure non-repudiation.
> 
> Igor
> 
> Dick Hardt wrote:
>> 
>> On 2010-03-12, at 10:22 AM, Eve Maler wrote:
>> 
>>> This nets out to the requesting party (person or company seeking access) 
>>> having an incentive to say "It's really me accessing this", such that it 
>>> mitigates the risk that the requester (client) will hand off both the 
>>> access token and the signing secret to a third party.
>> 
>> Note I am NOT a security expert, and would appreciate an education on where 
>> I am wrong.
>> 
>> When I look at this, I question if there really is that much more value in 
>> the Client having two secret items over one secret item. 
>> I can see an advantage with something like using RAS, in that only the 
>> Client should have the private key, and if the private key can be used for 
>> lots of things, then there is some difference between a token and the 
>> private key. With symmetric keys, multiple parties have the keys, so 
>> non-repudiation is not possible.
>> 
>> -- Dick
>> 
>> 
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>  

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] First draft of OAuth 2.0

[Dick Hardt]

David: perhaps if you asked the list about features before dropping
them we would not all have to argue with you about why to put them
back in. Frankly I was surprised that you did not circulate the draft
to me as editor of WRAP.

WG Chairs: Is this draft now the draft that the WG is working on and
is David now the editor for the WG?

-- Dick

On 2010-03-23, at 10:47 AM, David Recordon  wrote:

> Hey Chuck,
> Thanks for rewriting the SAML flow into the style of my draft!  I
> really appreciate it.
>
> I originally dropped the SAML flow because I hadn't seen support for
> it on the mailing list(s) the past two months.  I think that our
> default should be making the spec as short and simple as possible so
> removed a few things from WRAP in order to start conversations like
> this one.  It's now clear that Google, Microsoft, Salesforce, and IBM
> all need the SAML profile.  Chuck, I'll merge your wording in.  Want
> to be listed as an author?
>
> We're also going to need to figure out which flows should be in the
> core spec versus which should be developed at the same time but in
> individual documents.
>
> Thanks,
> --David
>
> On Tue, Mar 23, 2010 at 4:50 AM, Torsten Lodderstedt
>  wrote:
>> +1 for assertion support
>>
>> what about enhancing the flow #2.4 to accept any kind of user
>> credentials
>> (username/password, SAML assertions, other authz servers tokens)
>>
>> regards,
>> Torsten.
>>
>> Am 23.03.2010 um 12:42 schrieb Mark Mcgloin
>> :
>>
>>> +1 for assertion profile. Was there any reason why it was dropped?
>>>
>>> On 3/23/10, Chuck Mortimore wrote:

 Just getting a chance to review this – I apologize for not get
 ting this
>>>
>>> before the meeting started.
>>>
 We’d like to see some form of an Assertion Profile, similar to
  section
 5.2
>>>
>>> from draft-hardt-oauth-01.   We have strong customer use-cases for
>>> an
>>> assertion based flow, specifically SAML bearer tokens, and I
>>> >believe
>>> Microsoft may have already shipped a minor variation on this
>>> ( wrap_SAML )
>>> in Azure.
>>>
>>>
>>> Mark McGloin
>>> ___
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] First draft of OAuth 2.0

[Dick Hardt]

On 2010-03-23, at 12:05 PM, Chuck Mortimore wrote:

> No worries – I figured it would be easier to push for it’s inclusion if the 
> work were minimal.
> 
> We will definitely need to implement this style of profile, as will many 
> others, so it’s essential it ends in some spec.   Personally I’d rather see a 
> relatively thin spec that includes the critical profiles, rather than core + 
> profile + bindings + etc like SAML.   However I’m open to any approach that 
> get’s the profile included.
> 
> I’d be happy to be listed as an author, but it’s more important that whomever 
> authored the original assertion profile get listed/credit.   Not sure if that 
> was Dick or one of the other authors...perhaps they can chime in.

It was me, but David was not interested in getting my feedback let alone list 
me as an author prior to publication.

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] First draft of OAuth 2.0

[Dick Hardt]

On 2010-03-23, at 12:10 PM, David Recordon wrote:
> I'd like to pull the username/password and SAML flows into their own
> documents.  I don't think that we want to propagate the usage of the
> password anti-pattern and while I'm hearing clearly that the SAML flow
> is needed, I don't think it will be used by the majority of deployers.
> 
> We should develop both of these flows at the same time as the core
> spec so that they all go together.

Why is that? Many people don't think signatures should be there, but they are.
What would you save, a page or two? If layed out properly, a reader can 

By keeping all profiles in one document, someone easily understands the 
different applications of the technology, and when a different use case comes 
up, they know it is available rather than having to look at a different 
document.

-- Dick

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] First draft of OAuth 2.0

[Dick Hardt]

On 2010-03-23, at 12:16 PM, David Recordon wrote:

> On Tue, Mar 23, 2010 at 11:58 AM, Dick Hardt  wrote:
>> David: perhaps if you asked the list about features before dropping
>> them we would not all have to argue with you about why to put them
>> back in.
> 
> My goal by removing some of the non-obvious things was to encourage
> the discussion which has now started! Many of the design decisions
> that went into WRAP haven't entirely been shared in public. Since one
> of our major goals is developer simplicity it's reasonable to start
> with less and justify everything that's being added.  As the working
> group has seen, I'm really willing to add things back in once the
> reasoning has been explained (error codes, SAML flow, etc).

If you wanted to discuss, you could have posted questions about WRAP. I have 
promptly answered any questions people had. There are numerous changes in the 
spec where you just did not like the answer I gave you in the past.

> 
> 
>> Frankly I was surprised that you did not circulate the draft
>> to me as editor of WRAP.
> 
> I focused on getting feedback from consumer web deployers of OAuth 1.0
> (Twitter and Digg) who haven't participated in these discussions yet
> as they're extremely important to technology adoption.  I also spoke
> to Google, Microsoft, and Yahoo! as they were the three companies who
> developed WRAP together.  I'm sorry if I rubbed you the wrong way, but
> until this IETF meeting I didn't know that you were planning to deploy
> OAuth 2.0 as you were no longer working for Microsoft.  This shouldn't
> prevent us from working together on making OAuth 2.0 rock. :)

Hard to work with you when you just drop a whole bunch of changes and don't 
discuss them or ask for explanations.
I've been actively participating on the IETF list and on the calls. Not sure 
why I need to be working somewhere for my expertise and opinion to count. This 
is the IETF after all, and I was the editor of WRAP, so if you were going to 
incorporate WRAP, then it would seem logical to have included me. And given I 
have seen you in person numerous times in the last few weeks, it is not like 
you forgot I existed. Yes, I am miffed.



___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] Feedback on draft-recordon-oauth2-01

[Dick Hardt]

David

Although you stated you were taking WRAP and adding signatures, I found many 
other differences between the specs. I'm baffled at why you essentially started 
from scratch on this document rather than taking WRAP and adding the device 
profile and signatures. 

Per your previous email:

My goal by removing some of the non-obvious things was to encourage
the discussion which has now started

Here are numerous discussion points on your draft. I look forward to a response 
on each one.

-- Dick

1.2.1 The security and risk profile of a JavaScript or other RIA is different 
from a Rich App. The user can easily be fooled to run a RIA, but in general 
must be actively involved installed a Rich App. A RIA has an identity mechanism 
(URL it came from). Combining these makes it tougher to analyse the security 
issues and requires prohibits taking advantage of one context.

1.2.3 Google has been using captchas in their flows for some time. I'd like to 
hear from Google and others that have deployed captchas here that they do NOT 
want it as an option before it is removed.

1.2.4 I think this is a security consideration, not a specification MUST. Many 
use cases are fine moving cookies in the clear where the cookie.

1.2.5 All refresh token requests are not the same. I see that I mistakenly 
dropped a feature in draft-hardt-oauth-01. In 5.4.8 of WRAP 0.9.7.1 the refresh 
request also includes the client identifier and client secret. This enables a 
catastrophic loss of refresh tokens at a PR to be recovered by changing the 
client secret and not requiring the client to have to reacquire authorization 
from the user.

1.2.6 How is an AS supposed to mark an Access Token as no longer being valid? 
Are you implying that there is a Access Token revocation mechanism? I did not 
see where the spec discusses the invalidation of an Access Token. Did I miss it 
somewhere?

Other changes from WRAP that were not highlighted.

A) The User Delegation profiles were put in a separate section from the 
autonomous client flows to highlight to readers the difference in the flows. 
Your draft merges them which could be confusing. It was often confusing to 
readers of WRAP previously.

B) Change from using profile to flow. Personally I think flow is better. Would 
be interested to hear others thoughts.

C) Placement of Acquiring an Access Token prior to Accessing a Protected 
Resource. Most new readers will be Client or PR developers. What they care 
about is accessing a PR. Once they see that they need an Access Token to access 
a PR, they then understand they need to get an Access Token. They then can jump 
to the profile/flow that is relevant for them.

(D) The Parameter Considerations section was removed. We had found this section 
useful to collect common information about parameters.

1.3 Terminology

1.3 access token: why is this a now a unique identifier? the deployed usage of 
Access Tokens in WRAP is that this is a token, not an identifier. This was a 
significant feature in WRAP, that the Access Tokens are claims, not 
identifiers. This is also why the Access Token size could be larger. 

1.3 client: what do you mean by "OAuth-authenticated request"?
 
1.3 refresh token:. why does the refresh token need to be unique? can the AS 
hand the same one out to a client later on or does it need to track which ones 
it has handed out?

1.3 server: Why is server defined when we have protected resource? I don't 
understand the difference.

1.3.1 Why is this a subsection of Terminology? I find the use of the term 
server here very confusing. Is the PR a different machine? The Authorization 
Server? Why does the client discover them from the server?

1.3.1 255 character Access Token length recommendation. This was a joke right? 
There was a discussion of this on the list and no one was agreeing with 
Facebook reps on limiting the Access Token. Since it is a recommendation, 
people can go over, so what is the point? The real limit is what can be 
included in HTTP headers or in a query string, not the size of a MySQL record.

1.3.1 URL safe characters. What is the basis for this requirement? Many 
existing systems will likely have other non URL safe chars in their existing 
Access Tokens. You are now creating  Microsoft's deployed Simple Web Tokens 
that are used in WRAP are not URL safe.

1.3.1 Why is the Access Token length and character set in a section entitled 
Endpoints? Why did you drop Parameter Considerations? That section would have 
been the logical place to have included information such as this.

2 "five core flows" ... this implies any other flow is inferior. Why are they 
core? Per comment above, in WRAP we found it useful to separate the user 
delegation flows from the autonmous client flows.

2 "Common scenarios involve the resource owner delegating to a client to act on 
their behalf, adding another party (the resource owner) to the protocol."  
Which protocol is the resource owner being added to?

"U

[OAUTH-WG] new sponsorship, time available for WG

[Dick Hardt]

Microsoft recently offered to sponsor me to work on OAuth. For the past few 
months I have participated in the WG on my own time, but I am now able to 
devote a significant amount of time to this WG.

I'd be happy to work on merging client signature support with WRAP. My 
preference would be to start with that draft rather than draft-recordon-oauth2 
given all the capabilities that David decided to drop. Alternatively I will 
continue to provide criticism and author chunks of text if David is willing to 
include them in draft-recordon-oauth2.

At the IETF post meeting this week,  there was discussion of working on both 
draft-hardt-oauth and draft-recordon-oauth2.  David's draft has garnered much 
discussion, much of it comments on what was dropped from WRAP. Similarly, if 
draft-hardt-oauth was revised to include signatures, it likely would also 
generate discussion. Seems like a waste for the WG to be providing comments on 
two documents.

I'm unsure of the correct process: is it the chairs, the editor or a WG 
consensus call to decide where to start. 

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] First draft of OAuth 2.0

[Dick Hardt]

That was one of the reasons why the refresh was repeated. Unfortunately I 
dropped the secret mistakenly when I ported over to RFC format. See my comments 
on draft-recordon-oauth2 for details.

On 2010-03-23, at 6:51 PM, David Recordon wrote:

> What about clients which don't have access to the client secret? For
> example, rich desktop applications and devices.
> 
> Seems like if the client secret is optional then a server can enforce
> in policy what type of clients must pass it in.
> 
> --David
> 
> On Tue, Mar 23, 2010 at 5:56 PM, Brian Eaton  wrote:
>> On Tue, Mar 23, 2010 at 12:01 PM, David Recordon  wrote:
 §3
 - Why is the parameter oauth_client_secret required for refreshing access
 tokens? Use cases 2.2 and 2.3 do not require the client to use (possess) a
 secret. Does this imply such client are not entitled to refresh tokens? I
 would suggest to simply remove this parameter.
>>> 
>>> It shouldn't be required.  Fixed!
>>> http://github.com/daveman692/OAuth-2.0/commit/a30843724f241f3ea1052c83dcfec0127a11fe00
>> 
>> It was required in WRAP because is lets you recover if a client web
>> server that holds many refresh tokens is compromised.  You rotate the
>> client secret, and then the attacker loses access to user data.
>> 
>> Please add it back. =)
>> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] First draft of OAuth 2.0

[Dick Hardt]

On 2010-03-23, at 9:52 PM, Dick Hardt wrote:

>> My goal by removing some of the non-obvious things was to encourage
>> the discussion which has now started! Many of the design decisions
>> that went into WRAP haven't entirely been shared in public

Would you care to share the design decisions behind the choices you made in 
draft-recordon-oauth2 ?

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth