Re: [OAUTH-WG] OAuth 2.1: dropping password grant

[William Denniss]

On Mon, Feb 24, 2020 at 6:49 AM Neil Madden 
wrote:

> Well, kinda. People can still theoretically use OAuth 1 too, but the world
> has moved on - software has dropped support for it, websites don’t support
> it, and so on



> I’m a bit confused about what OAuth 2.1 is intended to be. If it’s not a
> new version of OAuth (“obsoletes” the old RFC), then is not just another
> BCP? If it is a new version and it removes grant types (OAuth 3.0?)


then that effectively has the same impact as removing them from OAuth 2.0,
> unless we’re envisioning some way for a client to negotiate version 2.0
> support from an AS?
>

Many implementations don't support the "password" grant today (and in fact,
never supported it), so it's not like you can rely on its presence for
interop.

If the client needs to negotiate which grant types it can use, then RFC
8414 provides this today with the "grant_types_supported" key.

William



>
> — Neil
>
> > On 22 Feb 2020, at 01:41, Dick Hardt  wrote:
> >
> > I'm a little confused on where this thread is going. If we take ROPC out
> of OAuth 2.1 then:
> >
> > 1) Existing deployments can keep using ROPC - why break it if it is
> working.
> >
> > 2) New deployments can use ROPC and be OAuth 2.0 compliant.
> >
> > 3) New deployments that don't need ROPC can be OAuth 2.1 compliant
>
> ___
> 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] WGLC on draft-ietf-oauth-incremental-authz-01

[William Denniss]

On Wed, Sep 25, 2019 at 3:54 PM Brian Campbell  wrote:

> Just noticed that something is missing in
> https://tools.ietf.org/html/draft-ietf-oauth-incremental-authz-02#section-5
> where it has just, "(Section 4.1.4 of )"
>

Thank you for catching this Brian. It was meant to read Section 4.1.4 of
RFC 6749.

I've updated this in my local copy, will get posted in version 04.


>
> On Thu, Sep 12, 2019 at 8:40 AM Hannes Tschofenig <
> hannes.tschofe...@arm.com> wrote:
>
>> Thanks for the correction; yes – the most recent version is -02 and I
>> posted an old link.
>>
>>
>>
>>
>>
>> *From:* Eve Maler 
>> *Sent:* Donnerstag, 12. September 2019 16:16
>> *To:* Hannes Tschofenig 
>> *Subject:* Re: [OAUTH-WG] WGLC on draft-ietf-oauth-incremental-authz-01
>>
>>
>>
>> I think you mean
>> https://tools.ietf.org/html/draft-ietf-oauth-incremental-authz-02?
>>
>> Eve Maler (sent from my iPad) | cell +1 425 345 6756 <(425)%20345-6756>
>>
>>
>> On Sep 11, 2019, at 4:22 AM, Hannes Tschofenig > > wrote:
>>
>> Hi all,
>>
>>
>>
>> We are starting a WGLC on the "OAuth 2.0 Incremental Authorization"
>> draft. You can find the document here:
>>
>> https://tools.ietf.org/html/draft-ietf-oauth-incremental-authz-01
>>
>>
>>
>> Please review the document and provide feedback.
>>
>>
>>
>> The WGLC will end September 25th, 2019.
>>
>>
>>
>> Ciao
>>
>> Hannes & Rifaat
>>
>> IMPORTANT NOTICE: The contents of this email and any attachments are
>> confidential and may also be privileged. If you are not the intended
>> recipient, please notify the sender immediately and do not disclose the
>> contents to any other person, use it for any purpose, or store or copy the
>> information in any medium. Thank you.
>>
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>> IMPORTANT NOTICE: The contents of this email and any attachments are
>> confidential and may also be privileged. If you are not the intended
>> recipient, please notify the sender immediately and do not disclose the
>> contents to any other person, use it for any purpose, or store or copy the
>> information in any medium. Thank you.
>> ___
>> 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] [Technical Errata Reported] RFC8252 (5848)

[William Denniss]

Process-wise I'm not sure if errata should be used to capture changing
implementation details like this. We expected the implementation details
that we documented in the appendix to change, and explicitly stated that
assumption. "The implementation details herein are considered accurate at
the time of publishing but will likely change over time.".

If updating those implementation details were in scope, then the proposed
text should needs to be revised before being accepted due to some
inaccuracies (e.g. SFSafariViewController is not a successor to
ASWebAuthenticationSession).

Best,
William

On Mon, Aug 26, 2019 at 12:04 PM RFC Errata System <
rfc-edi...@rfc-editor.org> wrote:

> The following errata report has been submitted for RFC8252,
> "OAuth 2.0 for Native Apps".
>
> --
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid5848
>
> --
> Type: Technical
> Reported by: Bayard Bell 
>
> Section: Appendix B.1
>
> Original Text
> -
> Apps can initiate an authorization request in the browser, without
> the user leaving the app, through the "SFSafariViewController" class
> or its successor "SFAuthenticationSession", which implement the in-
> app browser tab pattern.  Safari can be used to handle requests on
> old versions of iOS without in-app browser tab functionality.
>
> Corrected Text
> --
> Apps can initiate an authorization request in the browser, without
> the user leaving the app, through the "ASWebAuthenticationSession"
> class or its successors "SFAuthenticationSession" and
> "SFSafariViewController", which implement the in-app browser tab
> pattern.  The first of these allows calls to a handler registered
> for the AS URL, consistent with Section 7.2. The latter two classes,
> now deprecated, can use Safari to handle requests on old versions of
> iOS without in-app browser tab functionality.
>
> Notes
> -
> SFAuthenticationSession documentation reflects deprecated status:
>
>
> https://developer.apple.com/documentation/safariservices/sfauthenticationsession
>
> Here's the documentation for ASWebAuthenticationSession:
>
>
> https://developer.apple.com/documentation/authenticationservices/aswebauthenticationsession
>
> Instructions:
> -
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party
> can log in to change the status and edit the report, if necessary.
>
> --
> RFC8252 (draft-ietf-oauth-native-apps-12)
> --
> Title   : OAuth 2.0 for Native Apps
> Publication Date: October 2017
> Author(s)   : W. Denniss, J. Bradley
> Category: BEST CURRENT PRACTICE
> Source  : Web Authorization Protocol
> Area: Security
> Stream  : IETF
> Verifying Party : IESG
>
> ___
> 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] [Editorial Errata Reported] RFC8252 (5776)

[William Denniss]

This is an issue with the HTML auto generation, not the normative document.
I believe this errata should be rejected.

William

On Fri, 5 Jul 2019 at 06:56, RFC Errata System 
wrote:

> The following errata report has been submitted for RFC8252,
> "OAuth 2.0 for Native Apps".
>
> --
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid5776
>
> --
> Type: Editorial
> Reported by: Jan Dziekan 
>
> Section: GLOBAL
>
> Original Text
> -
>
>
> Corrected Text
> --
>
>
> Notes
> -
> RFC8252 references specific Sections of RFC6749, however urls are pointing
> to Sections in RFC8252.
> For example, in Section 6 there is a statement "code grant type per
> Section 4.1 of OAuth 2.0 [RFC6749]", where "Section 4.1" links to
> https://tools.ietf.org/html/rfc8252#section-4.1 instead of
> https://tools.ietf.org/html/rfc6749#section-4.1
> I have found such misplaced links in the following sections: 6, 8.2, 8.4,
> 8.5, 8.6, 8.12
>
> Instructions:
> -
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party
> can log in to change the status and edit the report, if necessary.
>
> --
> RFC8252 (draft-ietf-oauth-native-apps-12)
> --
> Title   : OAuth 2.0 for Native Apps
> Publication Date: October 2017
> Author(s)   : W. Denniss, J. Bradley
> Category: BEST CURRENT PRACTICE
> Source  : Web Authorization Protocol
> Area: Security
> Stream  : IETF
> Verifying Party : IESG
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] ID Token by Device Flow

[William Denniss]

Hi Taka,

On Mon, Jun 24, 2019 at 12:16 PM Takahiko Kawasaki 
wrote:

> Hi Justin,
>
> Thank you. Consensus will be that "openid" in the "scope" request
> parameter should trigger generation of an ID token.
>

+1, and the last time I checked, that’s how Google's implementation
behaved.

I'm wondering if the WG plans to mention it explicitly in the spec and add
> "acr_values" request parameter.
>

No plans to do this. The spec is in the edit queue so such a change can't
be made and as Justin said it may be more appropriate in OpenID Foundation,
if it's needed.

Best,
William


> Best Regards,
> Taka
>
>
> 2019年6月25日(火) 1:13 Justin Richer :
>
>> Taka,
>>
>> My reading is that the device flow, like other OAuth flows, does not
>> prohibit extension, including passing back identity assertions like the ID
>> Token. Since it inherits the token response from core OAuth 2, the ID Token
>> could be issued along side the access token just like in the authorization
>> code flow.The user is present and interacting at the AS in both cases. In
>> fact, I’d say that there are enough similarities between the two that for
>> the most part it should “just work” and fit the assumptions of most
>> clients. That said, it’s technically true that there is no defined profile
>> for the combination of the device flow and OIDC, but if something like that
>> were to be written it would be better fit to the OpenID Foundation.
>>
>> — Justin
>>
>> On Jun 20, 2019, at 6:32 PM, Takahiko Kawasaki  wrote:
>>
>> Hello,
>>
>> Do you have any plan to update the specification of Device Flow to
>> support issue of ID tokens?
>>
>> OAuth 2.0 Device Authorization Grant
>>
>> https://datatracker.ietf.org/doc/draft-ietf-oauth-device-flow/?include_text=1
>>
>> Best Regards,
>> Takahiko Kawasaki
>>
>> ___
>> 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] [Editorial Errata Reported] RFC6749 (5708)

[William Denniss]

+1 to Justin

Could this be handled in the extension spec potentially? Eg calling out
that OAuth has that requirement, but documenting an extension-specific case
that modifies it?

William


*From: *Justin Richer 
*Date: *Mon, May 13, 2019 at 11:06 AM
*To: *RFC Errata System
*Cc: *oauth@ietf.org

I see the intent of the change but I don’t think this is actually at the
> level of an erratum. This seems to be a normative change on a key extension
> point.
>
> Additionally, with the singleton nature imposed by the current text,
> there’s a 1:1 mapping between the request parameters and a JSON object, as
> would be found in a signed request object. Anything that changes that
> assumption should not be taken lightly.
>
> — Justin
>
> On Apr 29, 2019, at 8:29 AM, RFC Errata System 
> wrote:
>
> The following errata report has been submitted for RFC6749,
> "The OAuth 2.0 Authorization Framework".
>
> --
> You may review the report below and at:
> http://www.rfc-editor.org/errata/eid5708
>
> --
> Type: Editorial
> Reported by: Brian Campbell 
>
> Section: 3.1 and 3.2
>
> Original Text
> -
> Parameters sent without a value MUST be treated as if they were
> omitted from the request.  The authorization server MUST ignore
> unrecognized request parameters.  Request and response parameters
> MUST NOT be included more than once.
>
> Corrected Text
> --
> Parameters sent without a value MUST be treated as if they were
> omitted from the request.  The authorization server MUST ignore
> unrecognized request parameters.  Request and response parameters
> defined by this specification MUST NOT be included more than once.
>
> Notes
> -
> Adds the text "defined by this specification" to the last sentence to
> clarify that the restriction only applies to parameters defined in RFC 6749
> and not to unrecognized parameters or parameters defined by extension.
>
> Instructions:
> -
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party
> can log in to change the status and edit the report, if necessary.
>
> --
> RFC6749 (draft-ietf-oauth-v2-31)
> --
> Title   : The OAuth 2.0 Authorization Framework
> Publication Date: October 2012
> Author(s)   : D. Hardt, Ed.
> Category: PROPOSED STANDARD
> Source  : Web Authorization Protocol
> Area: Security
> Stream  : IETF
> Verifying Party : IESG
>
> ___
> 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] Benjamin Kaduk's No Objection on draft-ietf-oauth-device-flow-13: (with COMMENT)

[William Denniss]

On Sat, Oct 27, 2018 at 4:11 PM Benjamin Kaduk  wrote:

> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-oauth-device-flow-13: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-oauth-device-flow/
>
>
>
> --
> COMMENT:
> --
>
> Thank you for addressing my Discuss points.  I would still prefer to see a
> normative requirement for explicit user approval (as opposed to  just the
> descriptive statement that the chance to approve/deny should be offered),
> but I can understand the sentiment that such a requirement  on  the UI is
> not a matter for interoperability and could not be reliably enforced
> anyway.
>

Thank you again for your review.

The UI requirements not being a matter for interoperability is indeed why
there is no normative text for that, and we're following the approach taken
by other IETF OAuth specifications which also leave this up to the
implementors. I understand your concerns here, but I hope that the current
non-normative guidance is enough.



>
> Original COMMENT  section preserved below.
>
> Please use the RFC 8174 boilerplate instead of the RFC 2119 one.
>
> Section 3.2
>
> The example expires in 30 minutes?  That seems longer than needed; wouldn't
> 5 minutes do?
>
> Section 3.3
>
> I agree with directorate reviewer that the MUST NOT requirement for
> displaying the device_code should justify that requirement by discussing
> the consequences of exposure.
>
> Section 3.5
>
>authorization_pending
>   The authorization request is still pending as the end-user hasn't
>   yet completed the user interaction steps (Section 3.3).  The
>   client should repeat the Access Token Request to the token
>   endpoint.
>
> I feel like we want to mention the 'interval' here or some other discussion
> of an inter-request delay.
>
> Also, please clarify "reasonable default polling interval", per multiple
> directorate reviews.
>
> Section 5.2
>
> Please clarify the entities involved in "the backchannel flow" that can be
> MITM'd.
>
> Section 5.6
>
> The "short-range" part of a "short-range wireless signal" partially depends
> on how big the receiver's antenna is.  So perhaps we should be careful
> about indicating that this has more security value than it does.
>
> Section 6.1
>
> I'm not sure I understand the usage of "case-insensitive", here -- how
> would the user have an expectation of case-insensitivity?  Perhaps it is
> better to just say "majuscule" or "upper case" or whatever.
>
>
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

[William Denniss]

On Wed, Nov 28, 2018 at 2:51 PM n-sakimura  wrote:

> That works.
>
> In fact, I would further go and say MUST NOT but that probably is too much
> for a security consideration.
>
>
Personally I think it's fine for a MUST NOT to appear in a security
consideration section of a BCP. If you break it, then you're not following
the BCP.

We did exactly this in BCP 212:

"This best current
   practice requires that native apps MUST NOT use embedded user-agents
   to perform authorization requests
"

William

Nat Sakimura / n-sakim...@nri.co.jp / +81-90-6013-6276
>
>
> このメールには、本来の宛先の方のみに限定された機密情報が含まれている場合がございます。お心あたりのない場合は、誠に申し訳ございませんが、送信者までお知らせ頂き、また受信されたメールは削除してくださいますようお願い申し上げます。
>
> PLEASE READ :This e-mail is confidential and intended for the named
> recipient only.
> If you are not an intended recipient, please notify the sender and delete
> this e-mail.
>
> --
> *差出人:* Torsten Lodderstedt 
> *送信日時:* 水曜日, 11月 28, 2018 11:38 午後
> *宛先:* n-sakimura
> *Cc:* Dick Hardt; Hannes Tschofenig; oauth@ietf.org
> *件名:* Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization
> code instead of implicit
>
> Hi Nat,
>
> Am 28.11.2018 um 21:10 schrieb n-sakimura :
>
> I would support
>
> 1) clearly defining Implicit as the flow that returns access token from
> the authorization endpoint ( some people confuses implicit as the flow that
> returns ID Token in the front channel)
>
>
> That’s the current text:
>
> In order to avoid these issues, Clients SHOULD NOT use the implicit
>grant or any other response type causing the authorization server to
>issue an access token in the authorization response.
>
> What would you like to modify?
>
>
> 2) Banning the returning of the access token that are not sender
> constrained from the authorization endpoint
>
>
> In order to avoid these issues, Clients SHOULD NOT use the implicit
>grant or any other response type causing the authorization server to
>issue an access token in the authorization response*, if this access
> tokens is not sender-constraint.*
>
> What about this?
>
> kind regards,
> Torsten.
>
>
> Best,
>
> Nat
>
>
> Outlook for iOS を入手
>
> 差出人: OAuth  (Dick Hardt 
> の代理)
> 送信日時: 水曜日, 11月 28, 2018 8:58 午後
> 宛先: Hannes Tschofenig
> Cc: oauth@ietf.org
> 件名: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code
> instead of implicit
>
> +1
>
> While there are various mechanisms to alleviate some of the issues of
> implicit, I don't think we can recommend specifics, and there may be future
> ones in the future. I think we all agree that implicit without any
> mitigation is problematic.
>
> How about we recommend against using implicit alone?
>
>
> On Mon, Nov 19, 2018 at 2:34 AM Hannes Tschofenig <
> hannes.tschofe...@arm.com> wrote:
> Hi all,
>
> The authors of the OAuth Security Topics draft came to the conclusion that
> it is not possible to adequately secure the implicit flow against token
> injection since potential solutions like token binding or JARM are in an
> early stage of adoption. For this reason, and since CORS allows
> browser-based apps to send requests to the token endpoint, Torsten
> suggested to use the authorization code instead of the implicit grant in
> call cases in his presentation (see
> https://datatracker.ietf.org/meeting/103/materials/slides-103-oauth-sessb-draft-ietf-oauth-security-topics-01
> ).
>
> A hum in the room at IETF#103 concluded strong support for his
> recommendations. We would like to confirm the discussion on the list.
>
> Please provide a response by December 3rd.
>
> Ciao
>
> Hannes & Rifaat
>
>
>
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. 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
>
>
> ___
> 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] [Openid-specs-ab] OAuth Security Topics -- Recommend authorization code instead of implicit

[William Denniss]

In BCP 212 we currently recommend against using implicit flow for native
apps (Section 8.2), due to the inability to protect against interception
with PKCE. AppAuth iOS & Android don't implement it, and the JS version
didn't initially although it was requested by users who needed to do
implicit auth and was eventually supported.

To me the usefulness of implicit on the web is limited, as the code flow
can be used for public clients anyway. The one place I've seen implicit
come up in discussions was for situations where reducing complexity for
third-party developers who needed to implement an OAuth server was a high
priority (one less endpoint to implement).

+1 to have language recommending against the use in most cases (without
needing to exclude Nat's use-case). The code flow has better security
properties, and reducing optionality in the spec reduces the surface area
and simplifies implementations.


On Tue, Nov 27, 2018 at 12:36 PM, John Bradley via Openid-specs-ab <
openid-specs...@lists.openid.net> wrote:

> I understand that, but hat is Nat's concern as I understand it.
>
> When we say no implicit people, have a problem because implicit is
> imprecise.
>
> We are saying no AT returned in the response from the authorization
> endpoint.
>
> Nat points out that id_token may contain AT for the self issued client.
>
> So unless we say that is OK if the AT are sender constrained we wind up
> implying that a OpenID profile of OAuth is in violation of the BCP.
>
> I am just trying to make sure everyone is on the same page with why Nat
> was -1.
>
> It really has nothing to do with the SPA use case.
>
> John B.
>
>
> On 11/27/2018 5:28 PM, Torsten Lodderstedt wrote:
>
>> Hi John,
>>
>> as you said, self issued IDPs (https://openid.net/specs/open
>> id-connect-core-1_0.html#SelfIssued) are supposed to provide the
>> response type „id_token“ only. I don’t think the proposal being discussed
>> here is related to this OIDC mode.
>>
>> best regards,
>> Torsten.
>>
>> Am 27.11.2018 um 20:54 schrieb John Bradley :
>>>
>>> I talked to Nat about this a bit today.
>>>
>>> The thing he is concerned about is mostly around the self issued IDP
>>> that doesn't have a token endpoint(atleast not easaly).
>>>
>>> The main use case for that is the id_token response type where claims
>>> are retuned in the id_token.
>>>
>>> Because it is fragment encoded some people call that implicit.   That is
>>> not what we are trying to stop.
>>>
>>> In some cases in that flow there may be distributed claims returned with
>>> access Token inside the id_token.I think most people would agree that
>>> those should be pop or sender constrained tokens.
>>>
>>> In the case of self issued the RP would be a server and could do sender
>>> constrained via some mechinisim that is yet to be defined.
>>>
>>> So if someone wanted to return a access token in a id_token to do
>>> distributed claims I don't think we have a problem with that as long as the
>>> token is protected by being sender constrained in some reasonable way.
>>>
>>> This is a touch hypothetical from the basic OAuth perspective, so I
>>> don't know how deep we want to go into it.
>>>
>>> I think the point is not to accidently prohibit something that could be
>>> done in future.
>>>
>>> I also think we should not conflate confidential clients that can
>>> authenticate to the token endpoint with sender constrained/PoP clients that
>>> can deal with bound tokens.   Yes both have keys but it is better to
>>> describe them separately.
>>>
>>> John B.
>>>
>>> On Tue, Nov 27, 2018, 4:30 PM Torsten Lodderstedt via Openid-specs-ab <
>>> openid-specs...@lists.openid.net wrote:
>>> Hi Nat,
>>>
>>> I understand you are saying your draft could provide clients with an
>>> application level mechanism to sender constrain access tokens. That’s great!
>>>
>>> But I don’t see a binding to response type „token id_token“. Why do you
>>> want to expose the tokens via the URL to attackers?
>>>
>>> You could easily use your mechanism with code. That would also give you
>>> the chance to really authenticate the confidential client before you issue
>>> the token.
>>>
>>> kind regards,
>>> Torsten.
>>>
>>> Am 27.11.2018 um 16:57 schrieb Nat Sakimura :

 I am not talking about SPA.
 The client is a regular confidential client that is running on a server.

 Best,

 Nat Sakimura


 2018年11月27日(火) 16:55 Jim Manico :
 Nat,

 How is proof of possession established in a modern web browser in the
 implicit flow?

 My understanding is that token binding was removed from Chrome recently
 effectively killing browser-based PoP tokens.

 https://identiverse.com/2018/10/31/chrome-puts-token-binding-in-a-bind/

 Am I missing something?

 Aloha, Jim



 On 11/27/18 9:00 PM, Nat Sakimura wrote:

> I am actually -1.
>
> +1 for public client and the tokens that are not sender/key
> constrained.
>

Re: [OAUTH-WG] Dynamic Client Registration with Native Apps

[William Denniss]

If the secret is dynamically provisioned then you have a confidential
client. Anyone reverse engineering their own installation of the native app
would only extract their own client's credentials, as opposed to the shared
secret of all installations. Having a confidential client means that
requests to the token endpoint (code, refresh) are client authenticated, so
PKCE wouldn't be needed.

On Tue, Nov 27, 2018 at 1:44 AM, Christian Mainka <
Christian.Mainka=40rub...@dmarc.ietf.org> wrote:

> Hi,
>
> we just stumbled upon this [1] statement:
> "Except when using a mechanism like Dynamic Client Registration
>[RFC7591] to provision per-instance secrets, native apps are
>classified as public clients ..."
>
> What does this mean for us? Native App + Dynamic Client Registration =
> Confidential Client?
> Which threats are covered if Dynamic Client Registration is used on
> Native Apps?
>
> Best Regards,
> Vladi/Christian
>
> [1]: https://tools.ietf.org/html/rfc8252#section-8.4
>
> --
> Dr.-Ing. Christian Mainka
> Horst Görtz Institute for IT-Security
> Chair for Network and Data Security
> Ruhr-University Bochum, Germany
>
> Universitätsstr. 150, ID 2/463
> D-44801 Bochum, Germany
>
> Telefon: +49 (0) 234 / 32-26796
> Fax: +49 (0) 234 / 32-14347
> http://nds.rub.de/chair/people/cmainka/
> @CheariX
>
>
> ___
> 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] Benjamin Kaduk's Discuss on draft-ietf-oauth-device-flow-11: (with DISCUSS and COMMENT)

[William Denniss]

Hi Benjamin,

Thank you for your detailed review, and suggestions. Version 13 was just
posted, and incorporates your suggestions and feedback.

Replies inline:

On Thu, Aug 2, 2018 at 5:21 PM, Benjamin Kaduk  wrote:

> On Wed, Aug 01, 2018 at 05:16:52PM -0700, William Denniss wrote:
> > Benjamin,
> >
> > Thank you for the feedback. We just posted version 12 which addresses
> many
> > of your feedback points. Replies inline.
> >
> > On Tue, Jul 24, 2018 at 6:31 AM, Benjamin Kaduk  wrote:
> >
> > >
> > > --
> > > DISCUSS:
> > > --
> > >
> > > Let me preface this by noting that I'm not sure that all of these
> points
> > > are actionable; I would, however, like to discuss them.
> > >
> > > I'm really unhappy to not see any hard numbers on the entropy needed
> > > in a user code to provide a reasonable security margin with given
> > > parameters, and how it compares to the guessability bounds considered
> best
> > > practices in general (across protocols).  For example, we think 128-bit
> > > symmetric keys are okay because an attacker has to put in 2**96 work to
> > > have a 2**-32 chance of guessing correctly via brute force; the rate
> > > limiting and finite lifetime on the user code places an artificial
> limit on
> > > the amount of work an attacker can "do", so if one uses a 8-character
> > > base-20 user code (with roughly 34.5 bits of entropy), the
> rate-limiting
> > > interval and validity period would need to only allow 5 attempts in
> order
> > > to get the same 2**-32 probability of success by random guessing.
> > > Section 5.1 would be a great place for such text, near the preexisting:
> > >The user code SHOULD have enough entropy that when combined with
> rate
> > >limiting and other mitigations makes a brute-force attack
> infeasible.
> > >
> > >
> > Thank you for the comment, the authors are still considering the right
> way
> > to address this feedback.
> >
> >
> >
> > > We talk about "the authorization server", but any given *user* may
> have a
> > > relationship with multiple such ASes.  Can the Introduction make it
> more
> > > clear that the AS is associated with the device/client, and as such the
> > > it may not be the user's most-trusted AS?
> > >
> >
> > Sometimes the device is really an app on the device. E.g. a Roku TV
> device
> > (a "tv stick") that has several apps. Hulu, where the AS is hulu, and
> > YouTube, where the AS is YouTube (these are both "first party" use-cases
> > where the app and the AS are owned by the same entity). The user may also
> > have a Canon printer, which has a device flow to Google, to authorize it
> to
> > print documents (a "third-party" use-case).
> >
> > I'm not sure exactly what we should say in the introduction to address
> you
> > feedback here.
>
> The document text is currently referring to a single AS (the definite
> article "the" in "the authorization server" as if everyone knows which one
> to use as a prerequisite of using this flow.  That is presumably true for
> the devices in question, but it's not necessarily true for the reader of
> the spec.  So, I'd propose to say something like "connect to the device's
> authorization server to approve the access request" or "connect to the
> authorization server that the device trusts to mediate authorization
> decisions".  (Gosh, it's hard to write the second one without using
> "grant"!)
>

I added a section in the introduction to clarify the relationship of the
device to the AS:

   The device typically chooses the set of authorization servers to
   support (i.e., its own authorization server, or those by providers it
   has relationships with).  It is not uncommon for the device
   application to support only a single authorization server, such as
   with a TV application for a specific media provider that supports
   only that media provider's authorization server.  The user may not
   have an established relationship yet with that authorization

   provider, though one can potentially be set up during the
   authorization flow.


Does that improve the understanding of this concept? I can add the text
your propose directly too.


>
> > It also seems like a large latent risk with this flow is when the
> > > verification_uri_complete response is used along with

Re: [OAUTH-WG] Ben Campbell's No Objection on draft-ietf-oauth-device-flow-11: (with COMMENT)

[William Denniss]

Hi Ben,

Thank you for your feedback. Version 12 has been posted which addresses
some of your points. Replies inline:

On Wed, Aug 1, 2018 at 2:36 PM, Ben Campbell  wrote:

>
> --
> COMMENT:
> --
>
> Major Comment:
>
> I support Mirja's DISCUSS. (Otherwise, this would be a DISCUSS), but I
> have a
> slightly different spin on it. The device polls the server while waiting
> on the
> user to take action. Users are notoriously slow about that sort of thing.
> They
> might plug in a device then walk away for hours, days, or forever.  Now,
> consider that we are talking about IoT devices, so there may be millions of
> them. If they are fate shared in some way (imagine shipping day for a new
> popular product, or a software update that forces reauthorization, or a
> server
> coming back online after getting whacked the last time around), there
> could be
> millions of them trying this at the roughly the same time.
>
> Given all that, I think the draft really needs to give more detailed
> guidance
> on what sort of refresh rates, maximum attempts, expirations, back off
> patterns, etc might be reasonable from both network congestion and server
> overload perspectives.
>

Version 12 adds defaults for the interval, documents slow_down behavior,
and now requires that an expiry time is given (previously this was
optional).

Regarding maximum attempts, as that is a function of interval and the
expiry the AS can decide this (and also has the slow_down mechanism if they
need).


Other Substantive Comments:
>
> §3.1: What sort of events are expected to trigger the flow? In particular,
> I
> wonder if there should be guidance to make it unlikely to start the
> process by
> accident. For example, if the authorization process is kicked off by a
> device
> simply being plugged into power, a user might plug it in then walk away
> before
> realizing they had more to do. (See my major comment).
>

Added the text:

Due to the polling nature of this protocol, to avoid unneeded
requests on the token endpoint, the client SHOULD only commence a
device authorization request when prompted by the user, and not
automatically such as when the app starts.


> §3.3: What sort of bad thing could happen if the device_code is
> communicated to
> a user?


Nothing bad. This text was revised in 12 to clarify that this
recommendation is for usability.


> Do implementers need to worry about people  guessing device-codes?
>

Yes. Guessing the device_code would enable another device to obtain the
authorization grant once issued. We will add a security section in the next
version (13).


>
> §3.3, last paragraph: The "NOT RECOMMENDED" seems overly strong, given
> that the
> next section describes a perfectly good way to do exactly that. Maybe
> something
> like "NOT RECOMMENDED unless the device uses a non-textual mechanism for
> conveying the URL and code, such as that described in ..." would make
> sense?
>

The next section uses `verification_uri_complete` which is separate to
`verification_uri`, this NOT RECOMMENDED refers to the latter only. Also
the text immediately following the block you quoted reads "The next section
documents user interaction with "verification_uri_complete", which is
designed to carry this information." Even devices that use the non-textual
mechanism may also display the vanilla `verification_uri` and user_code as
a fallback, as Figure 3 shows, and so this NOT RECOMMENDED still applies to
the `verification_uri` that they display.

Figure 3 was updated to indicate that the user either scans the QR code
*or* follows the fallback options.


> §5.4: Are devices expected to know the operating environment in advance of
> deployment?
>

These apps typically are aware of the operating environments in which they
are deployed, e.g. a TV app deployed to a branded "TV streaming stick".


> Editorial Comments:
>
> §1, 3rd paragraph: The first sentence is hard to parse due the list of
> long,
> complex phrases. Please consider breaking into simpler sentences.
>

Added this to the -13 revision plan.



> §2: There are lower case instances of normative keywords.  Please consider
> using the updated boilerplate from RFC8174.
>

Done.

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

Re: [OAUTH-WG] Opsdir last call review of draft-ietf-oauth-device-flow-10

[William Denniss]

Qin,

Thank you for your valuable feedback. Version 12 incorporates some of your
feedback. Replies inline:

On Tue, Jun 12, 2018 at 4:25 AM, Qin Wu  wrote:

> Reviewer: Qin Wu
> Review result: Ready
>
> I have reviewed this document as part of the Operational directorate¡¯s
> ongoing
> effort to review all IETF documents being processed by the IESG.  These
> comments were written with the intent of improving the operational aspects
> of
> the IETF drafts. Comments that are not addressed in last call may be
> included
> in AD reviews during the IESG review.  Document editors and WG chairs
> should
> treat these comments just like any other last call comments. Document
> reviewed:
>  draft-ietf-oauth-device-flow
>
> Summary:
> This document defines device flow among browserless and input constrained
> devices, end user at browser and authorization server. This device flow
> allows
> OAuth clients to request user authorization from devices that have an
> Internet
> connection, but don't have an easy input method. This document is well
> written,
> especially security consideration section. I think it is ready for
> publication.
>
> Major issue: None
> Minor issue: Editorial
> Section 3.3.1
> The short name for NFV needs to be expanded, maybe add reference.
> QR code also needs to be expanded.
>

NFC and QR were expanded.


> Section 3.5:
> Who is token endpoint, how token endpoint is related to authorization
> server?
> Would it be great to add some clarification text about this.


This separation is covered in OAuth.

I added a some more references to OAuth 2 in Section 3.1 of version 12.

Could do the same in section 3.5.


> Section 4: Would

it be great to clarify the relationship between
> device_authorization_endpoint
> defined in this document and authorization_endpoint defined in
> draft-ietf-oauth-discovery-10 and explain why authorization_endpoint is not
> sufficient,e.g., draft-ietf-oauth-discovery-10 has already defined
> authorization server metadata value authorization_endpoint, however ¡­¡­
>
> Some text to clarify the distinction between these two endpoints was added
to Section 3.1

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

Re: [OAUTH-WG] Alexey Melnikov's No Objection on draft-ietf-oauth-device-flow-11: (with COMMENT)

[William Denniss]

Alexey,

Thank you for your feedback. Replies inline:

On Sun, Jul 29, 2018 at 9:26 AM, Alexey Melnikov 
wrote:

>
> --
> COMMENT:
> --
>
> This is generally a fine document and it was easy to follow.
>
> I am agreeing with Benjamin's DISCUSS about amount of entropy in codes.
>

Understood, we are working on this.


>
> In addition, the last para in Section 6.1 reads:
>
>The server should ignore any characters like punctuation that are not
>in the user-code character set.  Provided that the character set
>doesn't include characters of different case, the comparison should
>be case insensitive.
>
> This makes me uncomfortable, because you are talking of case-insensitivity,
> without fully specifying what it is. I assume that your advice only
> applies to user-code character sets which only use subset of ASCII?
> Because if you mean to extend your advice to full Unicode, you need more
> text
> and references here. Can you please clarify.
>

Version -12 updates this section.  It now reads, in part:

   For codes using
   only characters in the A-Z range as with the base-20 charset defined
   above, the user's input should be upper-cased before comparison to
   account for the fact that the user may input the equivalent lower-
   case characters.



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

Re: [OAUTH-WG] Benjamin Kaduk's Discuss on draft-ietf-oauth-device-flow-11: (with DISCUSS and COMMENT)

[William Denniss]

Benjamin,

Thank you for the feedback. We just posted version 12 which addresses many
of your feedback points. Replies inline.

On Tue, Jul 24, 2018 at 6:31 AM, Benjamin Kaduk  wrote:

>
> --
> DISCUSS:
> --
>
> Let me preface this by noting that I'm not sure that all of these points
> are actionable; I would, however, like to discuss them.
>
> I'm really unhappy to not see any hard numbers on the entropy needed
> in a user code to provide a reasonable security margin with given
> parameters, and how it compares to the guessability bounds considered best
> practices in general (across protocols).  For example, we think 128-bit
> symmetric keys are okay because an attacker has to put in 2**96 work to
> have a 2**-32 chance of guessing correctly via brute force; the rate
> limiting and finite lifetime on the user code places an artificial limit on
> the amount of work an attacker can "do", so if one uses a 8-character
> base-20 user code (with roughly 34.5 bits of entropy), the rate-limiting
> interval and validity period would need to only allow 5 attempts in order
> to get the same 2**-32 probability of success by random guessing.
> Section 5.1 would be a great place for such text, near the preexisting:
>The user code SHOULD have enough entropy that when combined with rate
>limiting and other mitigations makes a brute-force attack infeasible.
>
>
Thank you for the comment, the authors are still considering the right way
to address this feedback.



> We talk about "the authorization server", but any given *user* may have a
> relationship with multiple such ASes.  Can the Introduction make it more
> clear that the AS is associated with the device/client, and as such the
> it may not be the user's most-trusted AS?
>

Sometimes the device is really an app on the device. E.g. a Roku TV device
(a "tv stick") that has several apps. Hulu, where the AS is hulu, and
YouTube, where the AS is YouTube (these are both "first party" use-cases
where the app and the AS are owned by the same entity). The user may also
have a Canon printer, which has a device flow to Google, to authorize it to
print documents (a "third-party" use-case).

I'm not sure exactly what we should say in the introduction to address you
feedback here.

It also seems like a large latent risk with this flow is when the
> verification_uri_complete response is used along with an AS that assumes an
> authenticated user making such a verification request has approved the
> authorization (i.e., without an explicit user interaction to confirm), when
> that AS uses cookies or other persistent state to keep the user
> authenticated across multiple requests.  I could not find any MUST-level
> requirement for user interaction to confirm the device being authorized
> (even in Section 3.3, which covers the regular verificat_uri workflow!);
> please let me know if I missed something.  I would like to see some
> explicit text that (matching the flow described in Section 3.1 that
> requires the user to input the code) explicit user approval of the
> authorization is required.  (I do note that Section 5.3 has text about
> "SHOULD display information about the device.)
>

When verification_uri is used, the user has 2 steps (at least): 1. enter
code, 2. consent to the request. verification_uri_complete skips the first
step, but the presumption is that they would still consent to the request
in the second step. We can make this more clear if it isn't currently.

I'm also unhappy about the text in Section 1 that merely requires of the
> device the ability to "make outbound HTTPS requests", which leaves room for
> an awful lot of sins in certificate validation (and, potentially,
> ciphersuite selection).  Can we get a MUST-level requirement for
> authenticating the server and a cite to RFC 7525?
>

Reference to 7525 has been added.


> --
> COMMENT:
> --
>
> Please use the RFC 8174 boilerplate instead of the RFC 2119 one.
>

Done, thanks!


>
> Section 3.2
>
> The example expires in 30 minutes?  That seems longer than needed; wouldn't
> 5 minutes do?
>

Incidentally, 30 minutes is the value Google returns on the requests, which
was where this example came from.

In general I think it's good to have a reasonable window of time as the
user does need to find another device, open the browser, login to the AS
(possibly recover their passowrd), etc. There are some edge-cases in the
device flow too where if you enter the code right when it expires, you'll
get an error and need to start-over, and the longer the window of
opportunity the less this occurs.


>
> Section 3.3
>
> I agree with directorate reviewer that the MUST NOT requirement for
> displaying the device_code should justify that requirement 

Re: [OAUTH-WG] Call for adoption for "Resource Indicators for OAuth 2.0"

[William Denniss]

Yes there was.

+1 to adopt this document.


On Thu, Jul 19, 2018 at 2:11 PM, Dick Hardt  wrote:

> William: there was discussion in the meeting about the PoP document using
> "resource" rather than "aud"
>
> On Thu, Jul 19, 2018 at 4:53 PM, Mike Jones  c...@dmarc.ietf.org> wrote:
>
>> Microsoft’s Azure AD OAuth server has used the resource= parameter since
>> at least 2012 to indicate what resource the requested access token is to be
>> for.
>>
>>
>>
>>        -- Mike
>>
>>
>>
>> *From:* William Denniss 
>> *Sent:* Thursday, July 19, 2018 4:40 PM
>> *To:* Hannes Tschofenig 
>> *Cc:* Mike Jones ; oauth 
>> *Subject:* Re: [OAUTH-WG] Call for adoption for "Resource Indicators for
>> OAuth 2.0"
>>
>>
>>
>> Thanks! I assume then that there are use-cases for this that are outside
>> the Distributed OAuth use-case? Did we document them?  I'm supportive (of
>> both drafts), but think we should get the rationale on the record since the
>> option to incorporate this spec in Distributed OAuth was raised in the
>> meeting.
>>
>>
>>
>>
>>
>> On Thu, Jul 19, 2018 at 1:34 PM, Hannes Tschofenig <
>> hannes.tschofe...@arm.com> wrote:
>>
>> Hi William,
>>
>>
>>
>> that was the idea.
>>
>>
>>
>> Ciao
>>
>> Hannes
>>
>>
>>
>> *From:* OAuth [mailto:oauth-boun...@ietf.org] *On Behalf Of *William
>> Denniss
>> *Sent:* 19 July 2018 16:32
>> *To:* Mike Jones
>> *Cc:* oauth
>> *Subject:* Re: [OAUTH-WG] Call for adoption for "Resource Indicators for
>> OAuth 2.0"
>>
>>
>>
>> Question: if this is adopted along with https://datatracker.ietf.
>> org/doc/draft-hardt-oauth-distributed/, is the plan for this spec to be
>> the authoritative definition, and Distributed OAuth to take a reference
>> instead of redefining?
>>
>>
>>
>> On Thu, Jul 19, 2018 at 1:29 PM, Mike Jones <
>> Michael.Jones=40microsoft@dmarc.ietf.org> wrote:
>>
>> I support adoption.  The “resource” request parameter that it defines is
>> already widely used.
>>
>>
>>
>>-- Mike
>>
>>
>>
>> *From:* OAuth  *On Behalf Of *Rifaat Shekh-Yusef
>> *Sent:* Thursday, July 19, 2018 4:02 PM
>> *To:* oauth 
>> *Subject:* [OAUTH-WG] Call for adoption for "Resource Indicators for
>> OAuth 2.0"
>>
>>
>>
>> Hi all,
>>
>> This is the call for adoption of the 'Resource Indicators for OAuth 2.0'
>> document
>> following the positive call for adoption at the Montreal IETF meeting.
>>
>> Here is the document:
>> https://tools.ietf.org/html/draft-campbell-oauth-resource-indicators-02
>>
>> Please let us know by August 2nd whether you accept / object to the
>> adoption of this document as a starting point for work in the OAuth
>> working group.
>>
>> Regards,
>> Rifaat
>>
>>
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>>
>> IMPORTANT NOTICE: The contents of this email and any attachments are
>> confidential and may also be privileged. If you are not the intended
>> recipient, please notify the sender immediately and do not disclose the
>> contents to any other person, use it for any purpose, or store or copy the
>> information in any medium. 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] I-D Action: draft-ietf-oauth-incremental-authz-00.txt

[William Denniss]

Hi Torsten,

On Tue, Jul 17, 2018 at 7:57 AM, Torsten Lodderstedt <
tors...@lodderstedt.net> wrote:

> Hi William,
>
> please find below my review feedback.
>
> First of all, I think you managed to come up with the minimal extension
> needed to address a very relevant use case. Thanks!
>

Glad you like it! Thanks for reviewing.


> - Section 5, last paragraph.
>
> "the new refresh token issued in the Access Token Response (Section 4.1.4
> of ) SHOULD include authorization for the scopes in the previous grant.“
>
> Wouldn’t it be better to make that a MUST? Otherwise the client must
> assume the AS decides to not include all previously granted scopes, which
> in turn means the client must keep older grants (and hope the AS dd not
> automatically revolve it).
>

I was torn about this. From a protocol perspective you're not implementing
the protocol if you don't do that, so it should be a MUST. However, we need
to be careful that we defer to the provider when it comes to what
authorization is included as this is always their discretion.  I'll think
of a better way to word this so that it can be a MUST while still not
limiting the provider's discretion.


>
> - Section 6.1.1
>
> The section describes how a client should handle denial for incremental
> authorizations. How is the AS supposed to handle it? From the text one
> could deduce the AS should not discard any pre-existing granted scopes. Is
> that correct? Would it make sense to explicitly state that?
>

Good point. That section is mostly talking about the client, I'll add a
section for the server. I agree, the normal behavior would not be to revoke
previously granted scopes (which is how Google implements it).

Best,
William


> > Am 28.06.2018 um 22:14 schrieb internet-dra...@ietf.org:
> >
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> > This draft is a work item of the Web Authorization Protocol WG of the
> IETF.
> >
> >Title   : OAuth 2.0 Incremental Authorization
> >Author  : William Denniss
> >   Filename: draft-ietf-oauth-incremental-authz-00.txt
> >   Pages   : 8
> >   Date: 2018-06-28
> >
> > Abstract:
> >   OAuth 2.0 authorization requests that include every scope the client
> >   might ever need can result in over-scoped authorization and a sub-
> >   optimal end-user consent experience.  This specification enhances the
> >   OAuth 2.0 authorization protocol by adding incremental authorization,
> >   the ability to request specific authorization scopes as needed, when
> >   they're needed, removing the requirement to request every possible
> >   scope that might be needed upfront.
> >
> >
> > The IETF datatracker status page for this draft is:
> > https://datatracker.ietf.org/doc/draft-ietf-oauth-incremental-authz/
> >
> > There are also htmlized versions available at:
> > https://tools.ietf.org/html/draft-ietf-oauth-incremental-authz-00
> > https://datatracker.ietf.org/doc/html/draft-ietf-oauth-
> incremental-authz-00
> >
> >
> > Please note that it may take a couple of minutes from the time of
> submission
> > until the htmlized version and diff are available at tools.ietf.org.
> >
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/
> >
> > ___
> > 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] Last Call: (OAuth 2.0 Device Flow for Browserless and Input Constrained Devices) to Proposed Standard

[William Denniss]

On Thu, May 31, 2018 at 9:49 AM, Brian Campbell 
wrote:

>
>
> On Wed, May 30, 2018 at 6:06 PM, William Denniss 
> wrote:
>
>>
>> On Wed, May 30, 2018 at 3:48 PM, Brian Campbell <
>> bcampb...@pingidentity.com> wrote:
>>
>>> I realize this is somewhat pedantic but I don't think referencing 4.1.2.1
>>> works given how RFC 6749 set things up. Rather I believe that the device
>>> flow needs to define and register "access_denied" as a valid token
>>> endpoint
>>> response error code (it's not a token endpoint response error per RFC
>>> 6749
>>> sec 5.2 nor has it been registered https://www.iana.org/assignmen
>>> ts/oauth-parameters/oauth-parameters.xhtml#extensions-error
>>> <https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#extensions-error>
>>> ).  Also
>>> invalid_grant is a a token endpoint response error from RFC 6749 sec 5.2
>>> so
>>> that reference is needed and appropriate. RFC 6749 Sec 4.1.2.1
>>> <https://tools.ietf.org/html/rfc6749#section-4.1.2> defines errors
>>> returned
>>> from the authorization endpoint. But the device flow errors are from the
>>> token endpoint.
>>>
>>>
>> Yes, that's true. It's still the token endpoint, so 5.2 does in fact
>> apply, it's just we're mixing in authorization-style actions which were not
>> previously considered/used for that endpoint.
>>
>> Do you have any proposed text to resolve this?
>>
>>
>
> Sure, here's a crack at some text/changes:
>
>
> Add this to the list of error codes in section 3.5.:
>
> "access_denied
>The end-user denied the authorization request."
>
>
> And add this to section 7.2.1.:
>
>   "o  Error name: access_denied
>o  Error usage location: Token endpoint response
>o  Related protocol extension: [[ this specification ]]
>o  Change controller: IETF
>o  Specification Document: Section 3.5 of [[ this specification ]]"
>
>
> I might also slightly change this text in section 3.5:
>
> "In addition to the error codes defined in Section 5.2 of [RFC6749],
>the following error codes are specific for the device flow:"
>
> to
>
> "In addition to the error codes defined in Section 5.2 of [RFC6749],
>the following error codes are specified by the device flow:"
>
> so that the wording doesn't read as prohibiting the error codes from being
> used outside the device flow (access_denied from the token endpoint might
> well be useful for other grant types).
>
>
> And add "Andrew Sciberras" to the Acknowledgements.
>

Thank you Andrew for raising the point about needing to explicitly document
this error code, and Brian for your proposed text to resolve this, and for
the other issues you raised.

Version 10 has been posted by the authors to resolve the feedback received
so far during this last call:
https://tools.ietf.org/html/draft-ietf-oauth-device-flow-10
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Last Call: (OAuth 2.0 Device Flow for Browserless and Input Constrained Devices) to Proposed Standard

[William Denniss]

On Wed, May 30, 2018 at 3:48 PM, Brian Campbell 
wrote:

> I realize this is somewhat pedantic but I don't think referencing 4.1.2.1
> works given how RFC 6749 set things up. Rather I believe that the device
> flow needs to define and register "access_denied" as a valid token endpoint
> response error code (it's not a token endpoint response error per RFC 6749
> sec 5.2 nor has it been registered https://www.iana.org/assignmen
> ts/oauth-parameters/oauth-parameters.xhtml#extensions-error
> <https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#extensions-error>
> ).  Also
> invalid_grant is a a token endpoint response error from RFC 6749 sec 5.2 so
> that reference is needed and appropriate. RFC 6749 Sec 4.1.2.1
> <https://tools.ietf.org/html/rfc6749#section-4.1.2> defines errors
> returned
> from the authorization endpoint. But the device flow errors are from the
> token endpoint.
>
>
Yes, that's true. It's still the token endpoint, so 5.2 does in fact apply,
it's just we're mixing in authorization-style actions which were not
previously considered/used for that endpoint.

Do you have any proposed text to resolve this?


>
> On Wed, May 30, 2018 at 4:27 PM, William Denniss <
> wdenniss=40google@dmarc.ietf.org> wrote:
>
> > Hi Andrew,
> >
> > On Wed, May 30, 2018 at 3:18 PM, Andrew Sciberras <
> > andrewsciber...@pingidentity.com> wrote:
> >
> >> Hi William
> >>
> >> You are right that the document explicitly indicates which error codes
> >> may be returned. However I think it's ambiguous as to which error within
> >> Section 5.2 of RFC6749 would apply in the scenario of a user not
> granting
> >> access.
> >>
> >> I think that this ambiguity is highlighted further by the Google
> >> implementation (https://developers.google.com
> >> /identity/protocols/OAuth2ForDevices#step-6-handle-
> >> responses-to-polling-requests
> >> <https://developers..google.com/identity/protocols/OAuth2For
> Devices#step-6-handle-responses-to-polling-requests>)
> >> not adhering to the explicit statement of the document and electing to
> use
> >> a (more appropriate) error code that exists outside of section 5.2.
> >>
> >>
> >
> > Oh, I see what you mean now. Yes, given this is an authorization request,
> > not a token request, the errors from Section 4.1.2.1
> > <https://tools.ietf.org/html/rfc6749#section-4.1.2> are more relevant.
> >
> > I believe it was the authors intention to reference that set of errors,
> so
> > I will plan to update the doc to reference 4..1.2.1 instead.  Good catch!
> > Thank you.
> >
> >
> >>
> >> On Thu, May 31, 2018 at 8:06 AM, William Denniss 
> >> wrote:
> >>
> >>> Hi Andrew,
> >>>
> >>> On Wed, May 30, 2018 at 2:35 PM, Andrew Sciberras <
> andrewsciber...@pingidentity.com> wrote:
> >>>
> >>> Hello
> >>>>
> >>>>
> >>>> Do we feel that the document should be more specific in addressing how
> >>>> the authorization service should respond to a device access token
> request
> >>>> when the user has refused to grant access to the device?
> >>>>
> >>>>
> >>>> The document currently indicates in section 3.5 that a success
> response
> >>>> defined in section 5.1 of RFC6749, an error as defined in section 5.2
> of
> >>>> RFC6749 (this includes invalid_request, invalid_client, invalid_grant,
> >>>> unauthorized_client, unsupported_grant_type, and invalid_scope), or a
> new
> >>>> device flow error code (authorization_pending, slow_down, and
> >>>> expired_token) may be returned in a response to a device token request
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Publication has been requested for draft-ietf-oauth-device-flow-07

[William Denniss]

Thanks again for the feedback Scott. I've staged an update here:
https://github.com/WilliamDenniss/draft-ietf-oauth-device-flow/pull/6

It expands on the brute force attack section to include some detail on this
attack, as it is quite unique for OAuth brute-force attacks (since the
victim actually ends up with the attacker's grant on the device, instead of
the other way around – not that this is totally safe of course, it's just
unique).  It also adds some further discussion around what factors need to
be considered by authorization servers when creating the user code format.

I'll post this once my co-authors have reviewed, and the submission tool
re-opens.


On Fri, Jan 5, 2018 at 10:56 AM Rifaat Shekh-Yusef 
wrote:

> Hi Scott,
>
> Sorry, I missed that last discussion that you had with William.
>
>
> *William,*
>
> Can you please update the document based on your last discussion with
> Scott?
> I will then update the request for publication to use the new updated
> version.
>
> Regards,
>  Rifaat
>
>
>
> On Fri, Jan 5, 2018 at 12:40 PM, Hollenbeck, Scott <
> shollenb...@verisign.com> wrote:
>
>> > -Original Message-
>> > From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Rifaat Shekh-
>> > Yusef
>> > Sent: Friday, January 05, 2018 12:30 PM
>> > To: e...@rtfm.com
>> > Cc: oauth@ietf.org; iesg-secret...@ietf.org; oauth-cha...@ietf.org
>> > Subject: [EXTERNAL] [OAUTH-WG] Publication has been requested for draft-
>> > ietf-oauth-device-flow-07
>> >
>> > Rifaat Shekh-Yusef has requested publication of draft-ietf-oauth-device-
>> > flow-07 as Proposed Standard on behalf of the OAUTH working group.
>> >
>> > Please verify the document's state at
>> > https://datatracker.ietf.org/doc/draft-ietf-oauth-device-flow/
>>
>> The document really should be updated to reflect the last call
>> discussions prior to requesting publication for the -07 version that needs
>> to be updated.
>>
>> Scott
>>
>
> ___
> 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] Call for agenda items

[William Denniss]

Hannes & Rifaat,

I would like the opportunity to present on OAuth 2.0 Incremental
Authorization (draft-wdenniss-oauth-incremental-auth) [an update for which
will be posted today] and "OAuth 2.0 Device Posture Signals"
(draft-wdenniss-oauth-device-posture).

I can also give an update on the status of Device Flow
(draft-ietf-oauth-device-flow). I expect that to be short now that WGLC has
concluded and the document has advanced.

Little late to this thread and I see we already have 2 sessions in the
draft agenda, but I'd like to add my support to keeping both sessions,
there's always a lot to discuss and in the past we've been able to use any
spare time to discuss the security topics of the day.

Regards,
William




On Tue, Jan 30, 2018 at 4:40 AM Hannes Tschofenig 
wrote:

> Hi all,
>
>
>
> It is time already to think about the agenda for the next IETF meeting.
> Rifaat and I were wondering whether we need one or two sessions. We would
> like to make the decision based on the topics we will discuss. Below you
> can find a first version of the agenda with a few remarks. Let us know if
> you have comments or suggestions for additional agenda items.
>
>
>
> Ciao
> Hannes & Rifaat
>
>
>
> OAuth Agenda
>
> 
>
>
>
> - Welcome and Status Update  (Chairs)
>
>
>
>   * OAuth Security Workshop Report
>
>
>
>   * Documents in IESG processing
>
>  # draft-ietf-oauth-device-flow-07
>
>  # draft-ietf-oauth-discovery-08
>
>  # draft-ietf-oauth-jwsreq-15
>
>  # draft-ietf-oauth-token-exchange-11
>
>
>
>Remark: Status updates only if needed.
>
>
>
> -  JSON Web Token Best Current Practices
>
># draft-ietf-oauth-jwt-bcp-00
>
>
>
>Remark: We are lacking reviews on this document.
>
>Most likely we will not get them during the f2f meeting
>
>but rather by reaching out to individuals ahead of time.
>
>
>
> -  OAuth 2.0 Mutual TLS Client Authentication and Certificate Bound Access
> Tokens
>
># draft-ietf-oauth-mtls-06
>
>
>
>Remark: Could be completed by the time of the IETF meeting.
>
>
>
> - OAuth Security Topics
>
>   # draft-ietf-oauth-security-topics-04
>
>
>
>   Remark: We could do a consensus call on parts of the document soon.
>
>
>
> - OAuth 2.0 Token Binding
>
>   # draft-ietf-oauth-token-binding-05
>
>
>
>   Remark: Document is moving along but we are lacking implementations.
>
>
>
> - OAuth 2.0 Device Posture Signals
>
>   # draft-wdenniss-oauth-device-posture-01
>
>
>
>   Remark: Interest in the work but we are lacking content (maybe even
>
>   expertise in the group)
>
>
>
> - Reciprocal OAuth
>
>   # draft-hardt-oauth-mutual-02
>
>
>
>   Remark: We had a virtual interim meeting on this topic and there is
>
>   interest in this work and apparently no competing solutions. The plan
>
>   is to run a call for adoption once we are allowed to add a new milestone
>
>   to our charter.
>
>
>
> - Distributed OAuth
>
>   # draft-hardt-oauth-distributed-00
>
>
>
>   Remark: We had a virtual interim meeting on this topic and there is
>
>   interest in this work. Further work on the scope is needed.
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. 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] WGLC for OAuth 2.0 Device Flow for Browserless and Input Constrained Devices

[William Denniss]

On Fri, Dec 15, 2017 at 11:12 PM, Vladimir Dzhuvinov <
vladi...@connect2id.com> wrote:

> On 15/12/17 00:43, William Denniss wrote:
> > On Fri, Dec 8, 2017 at 11:42 AM, Vladimir Dzhuvinov <
> vladi...@connect2id.com
> >> wrote:
> >> Hi,
> >>
> >> I just got a question on Twitter about the slow_down error:
> >>
> >> https://tools.ietf.org/html/draft-ietf-oauth-device-flow-07#section-3.5
> >>
> >> The question was why slow_down is communicated via HTTP status code 400
> >> and not 429 (Too Many Requests).
> >>
> > We could, it seems to match the intent of that error code. Main reason
> it's
> > not like that so far is that 400 is the default for OAuth, I fear people
> > may not be checking for a 429. We don't strictly *need* the 429, since
> > we're returning data in machine readable format one way or another (i.e.
> > it's easy for the client to extract the "slow_down" response either way),
> > which differs from HTML over HTTP which is intended for end-user
> > consumption, making the specific status code more important.
> Yes, on a 400 clients will need to check the error JSON object anyway,
> so the "slow_down" cannot be missed. Whereas with 429 that becomes more
> likely.
>
> +1 to return "slow_down" with status 400 as it is with the other OAuth
> error codes.
>

Thanks for considering this Vladimir. To conclude this topic, it seems
there are no compelling reasons to change to the 429, and a reasonable
explanation of why it's a 400, so I think we should keep things as-is.

Rifaat: The deadline has passed on the WGLC, and I believe all comments
raised have been addressed. Can we now advance the draft?
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Token scanning attacks in RFC 7662

[William Denniss]

If you're interested in examples in the wild of token introspection without
client authentication, Google offers one and specifically recommends that
JS clients (which are public clients and thus can't use client
authentication) use it to mitigate confused deputy attacks on access
tokens. Documented here:
https://developers.google.com/identity/protocols/OAuth2UserAgent#validate-access-token
(section 5, select the "OAuth 2.0 Endpoints" tab). The endpoint doesn't
follow the spec precisely, as it pre-dated it, but it's pretty close.

Regarding that "MUST require authentication", it does seem like there are
other mitigations, including ones that the text eludes to (e.g. throttling,
high entropy, etc). I actually advocated for a watering down of the MUST at
IETF 93, but by then the document was too advanced along the publishing
process for chances to be considered. I gathered the intended use-case of
the spec was more for resource server rather than client introspection
(though I expressed a view that it could be expanded to cover both since it
was so close).

On Tue, Jan 2, 2018 at 9:01 AM, Neil Madden 
wrote:

> The requirement on 128-bit entropy is a MUST in RFC 6749. There is a
> SHOULD for the stronger 160-bit level. How does authentication address the
> problem?
>
> Neil
>
> > On 2 Jan 2018, at 15:06, John Bradley  wrote:
> >
> > In reality people developers may not always be putting that much entropy
> into a token.   It is only a SHOULD and hard to enforce.  I may have come
> up with the min entropy number.
> >
> > There may also be side channel attacks if you allow introspection of
> encrypted or signed tokens.
> >
> > There is also a potential privacy issue if you return a bunch of PII in
> the token response.  If the token leaked it perhaps can’t be used if it isa
> POP token but you may still leak PII via introspection.
> >
> > In general I am not a big fan of introspection.  We didn’t include it in
> Connect.  However the pattern is used in a number of commercial products to
> have the RS introspect tokens at the AS.
> > It was decided by the WG that having a standard would reduce the number
> of things people need to support when you have things like a DataPower
> talking to Ping Fed or something like that.
> >
> > Given that this is mostly used by RS I think the decision was made to
> err on the side of caution, as authentication is not a huge burden.
> > I recall it being discussed and some people didn’t want to do
> authentication.
> >
> > It is not cut and perhaps in some cases it might not be required,
> however that would introduce a option that people may get wrong in
> implementations.
> >
> > Happy New Year
> > John B.
> >
> >> On Jan 2, 2018, at 9:42 AM, Neil Madden 
> wrote:
> >>
> >> Greetings, and Happy New Year!
> >>
> >> I was just re-reading the OAuth 2.0 token introspection RFC 7662, and I
> am a bit confused by the rationale for requiring client (RS) authentication
> when making calls to this endpoint. The stated rationale in Section 2.1 (
> https://tools.ietf.org/html/rfc7662#page-5) is:
> >>
> >> “To prevent token scanning attacks, the endpoint MUST also require
> >>  some form of authorization to access this endpoint, such as client
> >>  authentication as described in OAuth 2.0 [RFC6749] or a separate
> >>  OAuth 2.0 access token such as the bearer token described in OAuth
> >>  2.0 Bearer Token Usage [RFC6750].”
> >>
> >> This rationale is elaborated in the Security Considerations:
> >>
> >> "If left unprotected and un-throttled, the introspection endpoint
> >>  could present a means for an attacker to poll a series of possible
> >>  token values, fishing for a valid token.  To prevent this, the
> >>  authorization server MUST require authentication of protected
> >>  resources that need to access the introspection endpoint and SHOULD
> >>  require protected resources to be specifically authorized to call the
> >>  introspection endpoint.”
> >>
> >> However, RFC 6749 already requires that access tokens be unguessable
> with a probability of successful guesses being at most 2^(-128) [
> https://tools.ietf.org/html/rfc6749#section-10.10]. Assuming that this
> means something like: if an attacker makes 2^n guesses then they have a
> maximum chance of guessing a particular access token of at most 2^(n-128),
> then I think the token scanning attacks are already taken care of aren’t
> they? It is not feasible for an attacker to make that many queries. Even if
> you consider that the attacker only needs to guess one out of the set of
> all valid access tokens, then I still don’t think this attack is feasible
> in any realistic time-frame, especially if you follow the “SHOULD"
> recommendation to require at most 2^(-160) probability.
> >>
> >> Is there some other threat model being considered here? Timing
> side-channels maybe?
> >>
> >> Also, I cannot find a justification in the RFC for how this threat is
> 

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

[William Denniss]

This suggestion was considered by the working group, I raised the proposal
at IETF98, you can see the recording 
.

The WG rejected the inclusion of this construct in the device flow
specification, but as Justin suggested, the door is open for a standalone
document so that it could be useful for *all* OAuth clients, not just
device flow ones.

On Mon, Dec 11, 2017 at 12:41 PM, Justin Richer  wrote:

> This could be useful but shouldn’t be done in a way that’s tied to the
> device flow — any public client would suffer from the same fate.
>
>  — Justin
>
> > On Dec 11, 2017, at 3:19 PM, Jaap Francke 
> wrote:
> >
> > Hi all,
> >
> > I have previously made the following suggestion which still makes sense
> to me.
> >
> > […]we were working with one of our customers to implement the device
> flow as part of our IDaaS.
> > One of the requirements was the ability to revoke tokens for one of the
> devices at the Resource Server.
> >
> > In our use case, we used the terminolgy ‘pairing a device to the
> enduser’s account’ to describe the process of authorising a device to
> access the resource owner’s resources.
> > The resource owner may want to ‘unpair’ a device from a list of paired
> devices without having access to the device itself (anymore). Think about a
> stolen/lost kind of situation.
> > We are looking for ways to allow the user to unpair one of his devices
> at the Authorisation Server.
> > Since the Device Flow exchanges only the ‘generic’ client_id with the
> Authorisation Server, there is no logical way at the Resource Server to
> make a distinction between various devices (having the same client_id) that
> may be paired to the same Resource Owner.
> >
> > My suggestion is the following
> > - add an optional parameter to the device authorisation request (or
> device access token request): 'device_identifier'. A device can use this to
> make (for example) its serial-number known at the Resource Server.
> > - add an optional parameter to the device access token response that
> allows to communicate a name for the device as may have been given to it by
> the resource owner while allowing the clients access (E). This parameter
> could be something like ‘device_name’. The device may be able to display
> this ‘device_name’ on its display.
> >
> > Please consider this as a suggested enhancement of the Device Flow
> specifications.
> >
> >
> > Kind regards,
> >
> > Jaap
> >> On 11 Dec 2017, at 18:56, oauth-requ...@ietf.org wrote:
> >>
> >> Send OAuth mailing list submissions to
> >>  oauth@ietf.org
> >>
> >> To subscribe or unsubscribe via the World Wide Web, visit
> >>  https://www.ietf.org/mailman/listinfo/oauth
> >> or, via email, send a message with subject or body 'help' to
> >>  oauth-requ...@ietf.org
> >>
> >> You can reach the person managing the list at
> >>  oauth-ow...@ietf.org
> >>
> >> When replying, please edit your Subject line so it is more specific
> >> than "Re: Contents of OAuth digest..."
> >>
> >>
> >> Today's Topics:
> >>
> >>  1. Re: WGLC for OAuth 2.0 Device Flow for Browserless and Input
> >> Constrained Devices (Brian Campbell)
> >>  2. Re: I-D Action: draft-ietf-oauth-token-exchange-10.txt
> >> (Justin Richer)
> >>
> >>
> >> --
> >>
> >> Message: 1
> >> Date: Mon, 11 Dec 2017 09:46:09 -0700
> >> From: Brian Campbell 
> >> To: Rifaat Shekh-Yusef 
> >> Cc: oauth 
> >> Subject: Re: [OAUTH-WG] WGLC for OAuth 2.0 Device Flow for Browserless
> >>  and Input Constrained Devices
> >> Message-ID:
> >>   m...@mail.gmail.com>
> >> Content-Type: text/plain; charset="utf-8"
> >>
> >> I couldn't get the QR code to work... ;)
> >>
> >> On Mon, Nov 27, 2017 at 6:55 AM, Rifaat Shekh-Yusef <
> rifaat.i...@gmail.com>
> >> wrote:
> >>
> >>> All,
> >>>
> >>> As discussed in Singapore, we are starting a WGLC for the
> >>> *draft-ietf-oauth-device-flow-07* document, starting today and ending
> on
> >>> December 11, 2018.
> >>> https://datatracker.ietf.org/doc/draft-ietf-oauth-device-flow/
> >>>
> >>> Please, review the document and provide feedback on the list.
> >>>
> >>> Regards,
> >>> Rifaat & Hannes
> >>>
> >>>
> >>> ___
> >>> OAuth mailing list
> >>> 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.*
> >> 

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

[William Denniss]

On Mon, Dec 11, 2017 at 8:46 AM, Brian Campbell 
wrote:

> I couldn't get the QR code to work... ;)
>

Mild shock! ;-)


> On Mon, Nov 27, 2017 at 6:55 AM, Rifaat Shekh-Yusef  > wrote:
>
>> All,
>>
>> As discussed in Singapore, we are starting a WGLC for the
>> *draft-ietf-oauth-device-flow-07* document, starting today and ending on
>> December 11, 2018.
>> https://datatracker.ietf.org/doc/draft-ietf-oauth-device-flow/
>>
>> Please, review the document and provide feedback on the list.
>>
>> Regards,
>>  Rifaat & Hannes
>>
>>
>> ___
>> OAuth mailing list
>> 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] Adam Roach's No Objection on draft-ietf-oauth-native-apps-11: (with COMMENT)

[William Denniss]

Thanks Adam for your feedback, and reviewing the work in progress! v12
<https://tools.ietf.org/html/draft-ietf-oauth-native-apps-12> is out now
with those and other IESG review related changes.

On Fri, Jun 2, 2017 at 8:01 PM, Adam Roach <a...@nostrum.com> wrote:

> On 6/2/17 21:25, William Denniss wrote:
>
> In my staged copy
> <https://github.com/WilliamDenniss/draft-ietf-oauth-native-apps/pull/9/files>,
> I have followed your advice and reversed the recommendation ordering, and
> mentioned the caveats that the user's personalisations are not present in
> the broker. The lack of password manager support is a very good point. It's
> definitely been one of the advantages we've seen by moving to browsers from
> web-view.
>
>
> Thanks! The new text in the Windows section looks great.
>
> /a
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Ben Campbell's No Objection on draft-ietf-oauth-native-apps-11: (with COMMENT)

[William Denniss]

Thank you for your review.

We've reworked section 8.7 to move the focus away from the user regarding
mitigations for apps that fake external user-agents.

On Tue, May 23, 2017 at 2:48 PM, Ben Campbell  wrote:

> Ben Campbell has entered the following ballot position for
> draft-ietf-oauth-native-apps-11: No Objection
>
> --
> COMMENT:
> --
>
> I agree with Adam's general sentiment about detection of bad behavior vs
> asking people not to be bad.
>
> -8 and it's children: There seems to be a lot of duplication (including
> duplication of normative language) between the security considerations
> and the rest of the document.
>
> - 8.7: This section seems to argue against using in-app browser tabs in
> the first place. If there is no good way for the user to tell the
> difference between that and an imbedded UA, then maybe we should train
> users to be suspicious of any in-app presentation of the authorization
> request? The last paragraph seems to be founded on a mismatch between
> user needs and typical user sophistication.
>
>
>
Re-worked this section a lot with a focus on actionable steps that
authorization servers and app stores can take.  Also covers some "detection
of bad behavior".
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Adam Roach's No Objection on draft-ietf-oauth-native-apps-11: (with COMMENT)

[William Denniss]

On Tue, May 23, 2017 at 9:53 AM, Adam Roach <a...@nostrum.com> wrote:

> On 5/23/17 05:09, Alexey Melnikov wrote:
>
> On Tue, May 23, 2017, at 10:24 AM, Alexey Melnikov wrote:
>
> Hi William,
>
> On 22 May 2017, at 23:14, William Denniss <wdenn...@google.com> wrote:
>
> Section 8.1 makes the statement that "Loopback IP based redirect URIs may
> be susceptible to interception by other apps listening on the same
> loopback interface." That's not how TCP listener sockets work: for any
> given IP address, they guarantee single-process access to a port at any
> one time. (Exceptions would include processes with root access, but an
> attacking process with that level of access is going to be impossible to
> defend against). While mostly harmless, the statement appears to be false
> on its face, and should be removed or clarified.
>
>
> Will be removed in the next update. Thank you.
>
>
> Actually, I disagree with Adam on this, because what he says is OS
> specific. So I think the text is valuable and should stay.
>
> In particular, I think SO_REUSEADDR socket option is widely implemented,
> both on Windows and Linux.
>
>
> Okay, after doing a lot of digging, this appears to be much more
> complicated than it should be [1]. Linux (as of 3.9) does allow multiple
> _listeners_ on a single IP/Address pair (and does load balancing among them
> o_O), but only if they're both using SO_REUSEADDR ("don't do that then"
> would be good advice). Windows allows the kind of hijacking described in
> the document unless SO_EXCLUSIVEADDRUSE is set (and it might be good advice
> in this document to suggest setting it).
>

Thank you Alexey and Adam for the discussion and research!

I've added notes to both the Windows and Linux implementation details
(staged for v12).


> So I'm okay with the paragraph staying in, although I would like to see it
> qualified with "on some operating systems", and would like to see a note
> (probably in section B.3) recommending the use of SO_EXCLUSIVEADDRUSE on
> listening sockets.
>

Added the qualifier "on some operating systems" for the next version.

/a
>
>
> 
>
> [1] The most comprehensive explanation of facts on the ground that I could
> find is https://stackoverflow.com/questions/14388706/socket-
> options-so-reuseaddr-and-so-reuseport-how-do-they-differ-do-they-mean-t
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] [OPS-DIR] Opsdir telechat review of draft-ietf-oauth-native-apps-10

[William Denniss]

Thanks for your review Zitao!

Version 12 addresses your comments. Detailed responses below:

On Sun, May 21, 2017 at 8:05 PM, wangzitao  wrote:

> Reviewer: Zitao Wang (Michael)
>
> Review result: Has Nits
>
>
>
> I have reviewed this document as part of the Operational
> directorate’s ongoing effort to review all IETF documents being processed
> by the IESG.  These comments were written with the intent of improving the
> operational aspects of the IETF drafts. Comments that are not addressed in
> last call may be included in AD reviews during the IESG review.  Document
> editors and WG chairs should treat these comments just like any other last
> call comments.
>
>
>
> Document reviewed:  draft-ietf-oauth-native-apps-10
>
>
>
> Summary:
>
>
>
> OAuth 2.0 authorization requests from native apps should only be made
>
> through external user-agents, primarily the user’s browser. This
>
> specification details the security and usability reasons why this is
>
> the case, and how native apps and authorization servers can implement
>
> this best practice.
>
>
>
> I think the document is written very clear, except some small nits:
>
> Page 3: The last sentence of introduction-- “This practice is also
> known as the AppAuth pattern”.
>
> I suggest adding a reference to explain the AppAuth pattern.
>
>
Done


> Page 3: Terminology -- "OAuth".
>
> I suggest modifying to: "OAuth"   The Web Authorization (OAuth) protocol.
> In this document, OAuth refers to OAuth 2.0 [RFC6749].
>
I went with:
"In this document, OAuth refers to the OAuth 2.0 Authorization Framework
[RFC6749]."

The phrase "Web Authorization (OAuth) protocol" only seems to appear in our
WG Charter, and not general usage
.


> Page 4: Terminology -- "web-view"  A web browser UI component.
>
> Does it mean "User Information"?  Suggest expanding this abbreviation.
>
>
Done.


> Page 5: Figure 1.   Does the browser and authorization endpoint are
> some kinds of "external user-agent"? Suggest describing it more clearly.
>

Now states:
"illustrates the interaction of the native app with a browser
external user-agent to authorize the user. "

Page   9:   PKCE [RFC7636] details how this limitation can be used to
> execute a code interception attack (see Figure 1).
>
> Does the Figure 1 means “Figure 1 of RFC7636”?
>

Good catch. I delete the figure reference, since the entire spec talks
about this attack, which is likely sufficient.


>
> Page10: However, as the Implicit Flow cannot be protected by PKCE
>
> Seems here, the reference be omitted.
>

Added.


> A run of idnits revealed no errors, flaws. There were 1 warning and 1 
> comments though
>
>
>
>   == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the
>
>  document.
>
>
>
>
I ran it myself with verbose output, and got:

tmp/draft-ietf-oauth-native-apps__1_.txt(435): Found possible FQDN
'com.example.app' in position 5; this doesn't match RFC 2606's
suggested ".example" or ".example.(com|org|net)".


We are actually using a RFC2606 domain name here, but in reverse domain
name notation which is causing this warning.

No changes required.


>   Miscellaneous warnings:
>
>   
>
>
>
>   -- The document date (April 26, 2017) is 14 days in the past.  Is this
>
>  intentional?
>
>
>
>
>
>   Checking references for intended status: Best Current Practice
>
>   
>
>
>
>  (See RFCs 3967 and 4897 for information about using normative references
>
>  to lower-maturity documents in RFCs)
>
>
>
>  No issues found here.
>
>
>
>  Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--).
>
>
>
>
>
> ___
>
> OPS-DIR mailing list
>
> ops-...@ietf.org
>
> https://www.ietf.org/mailman/listinfo/ops-dir
>
>
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Call for Adoption: Mutual TLS Profiles for OAuth Clients

[William Denniss]

I support the adoption of this draft by the working group.

On Sun, Apr 23, 2017 at 9:11 AM, Torsten Lodderstedt <
tors...@lodderstedt.net> wrote:

> +1 for adoption
>
> Am 21.04.2017 um 21:43 schrieb Nat Sakimura :
>
> +1 for adoption
>
> On Apr 21, 2017 9:32 PM, "Dave Tonge"  wrote:
>
>> I support adoption of draft-campbell-oauth-mtls
>>
>> As previously mentioned this spec will be very useful for Europe where
>> there is legislation requiring the use of certificate-based authentication
>> and many financial groups and institutions are considering OAuth2.
>>
>> The UK Open Banking Implementation Entity has a strong interest in using
>> this spec.
>>
>> Dave
>>
>> On 20 April 2017 at 17:32, Hannes Tschofenig 
>> wrote:
>>
>>> Hi all,
>>>
>>> based on the strong support for this document at the Chicago IETF
>>> meeting we are issuing a call for adoption of the "Mutual TLS Profiles
>>> for OAuth Clients" document, see
>>> https://tools.ietf.org/html/draft-campbell-oauth-mtls-01
>>>
>>> Please let us know by May 4th whether you accept / object to the
>>> adoption of this document as a starting point for work in the OAuth
>>> working group.
>>>
>>> Ciao
>>> Hannes & Rifaat
>>>
>>>
>>> ___
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>>
>>
>>
>> --
>> Dave Tonge
>> CTO
>> [image: Moneyhub Enterprise]
>> 
>> 10 Temple Back, Bristol, BS1 6FL
>> t: +44 (0)117 280 5120 <+44%20117%20280%205120>
>>
>> Moneyhub Enterprise is a trading style of Momentum Financial Technology
>> Limited which is authorised and regulated by the Financial Conduct
>> Authority ("FCA"). Momentum Financial Technology is entered on the
>> Financial Services Register (FRN 561538) at fca.org.uk/register.
>> Momentum Financial Technology is registered in England & Wales, company
>> registration number 06909772 © . Momentum Financial Technology Limited
>> 2016. DISCLAIMER: This email (including any attachments) is subject to
>> copyright, and the information in it is confidential. Use of this email or
>> of any information in it other than by the addressee is unauthorised and
>> unlawful. Whilst reasonable efforts are made to ensure that any attachments
>> are virus-free, it is the recipient's sole responsibility to scan all
>> attachments for viruses. All calls and emails to and from this company may
>> be monitored and recorded for legitimate purposes relating to this
>> company's business. Any opinions expressed in this email (or in any
>> attachments) are those of the author and do not necessarily represent the
>> opinions of Momentum Financial Technology Limited or of any other group
>> company.
>>
>> ___
>> 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] I-D Action: draft-ietf-oauth-device-flow-04.txt

[William Denniss]

My coauthors and I posted draft 04 of the OAuth 2.0 Device Flow for
Browserless and Input Constrained Devices draft today.

Key changes:

   1. Title updated to reflect specificity of devices that use this flow.
   2. User interaction section expanded.
   3. OAuth 2.0 Metadata
   <https://tools.ietf.org/html/draft-ietf-oauth-discovery> for the device
   authorization endpoint added.
   4. User interaction section expanded.
   5. Security Considerations section added.
   6. Usability Considerations section added.

Please give it a look!

On Mon, Feb 27, 2017 at 9:46 AM, <internet-dra...@ietf.org> wrote:

>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Web Authorization Protocol of the IETF.
>
> Title   : OAuth 2.0 Device Flow for Browserless and Input
> Constrained Devices
>     Authors : William Denniss
>   John Bradley
>   Michael B. Jones
>   Hannes Tschofenig
> Filename: draft-ietf-oauth-device-flow-04.txt
> Pages   : 15
> Date: 2017-02-27
>
> Abstract:
>This OAuth 2.0 authorization flow for browserless and input
>constrained devices, often referred to as the device flow, enables
>OAuth clients to request user authorization from devices that have an
>Internet connection, but don't have an easy input method (such as a
>smart TV, media console, picture frame, or printer), or lack a
>suitable browser for a more traditional OAuth flow.  This
>authorization flow instructs the user to perform the authorization
>request on a secondary device, such as a smartphone.  There is no
>requirement for communication between the constrained device and the
>user's secondary device.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-oauth-device-flow/
>
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-oauth-device-flow-04
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-device-flow-04
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> ___
> 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] Device Flow: Alternative to Polling

[William Denniss]

We've been operating with polling for a while and handle a decent amount of
traffic (the YouTube TV app uses it), the polling gets the job done. The
simplicity of the protocol definitely helps when used on constrained
devices.

I like the idea of adding HTTP/2 based long-poll as an optional
enhancement, especially if we can define it in ways that don't alter the
underlying protocol a whole lot.

On Fri, Oct 21, 2016 at 3:35 PM, Aaron Parecki  wrote:

> Part of the beauty of the current device flow spec is that it's so simple
> to support. Keeping that simplicity is crucial especially for this, since
> this flow is used by a variety of devices that often do not have higher
> level stacks.
>
> I would love to hear from someone who has experience with large-scale
> deployments of this to know whether polling is even a problem in the first
> place.
>
> 
> Aaron Parecki
> aaronparecki.com
> @aaronpk 
>
> 
> Aaron Parecki
> aaronparecki.com
> @aaronpk 
>
>
> On Fri, Oct 21, 2016 at 3:23 PM, Hannes Tschofenig <
> hannes.tschofe...@gmx.net> wrote:
>
>> Hi all,
>>
>> the device flow document outlines the case when an OAuth interaction
>> gets "outsourced" to a separate device in order to allow user
>> authentication and collecting the consent.
>>
>> The exchange is described in Section 1 of
>> https://tools.ietf.org/html/draft-ietf-oauth-device-flow-03.
>>
>> Here is the step that was raised during the discussions:
>>
>>   (E) While the end-user authorizes (or denies) the client's request
>>   (D), the client repeatedly polls the authorization server to find
>>   out if the end-user completed the end-user authorization step.
>>   The client includes the verification code and its client
>>   identifier.
>>
>> The question was whether we could come up with an alternative to polling
>> since this step could potentially take some time. Hence, it would be
>> better if the authorization server has a way to send a message to the
>> client without polling. Of course, the polling frequency matters and how
>> quickly one (e.g., user) wants to know about the successful authorization.
>>
>> So, the first question is whether polling is considered as a problem in
>> the first place.
>>
>> If so, then the question is how this could be addressed and (from work
>> in other areas) there are really only two approaches:
>>
>> 1) We make use of some protocol that keeps the connection open and allow
>> asynchronous communication. HTTP/2 and Websockets come to mind.
>>
>> 2) The client can be addressed through some push notification mechanism,
>> such as by running an HTTP server on the device that can then be used by
>> the authorization server.
>>
>> Any views about this topic?
>>
>> Ciao
>> 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
>
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Shepherd Writeup for OAuth 2.0 for Native Apps

[William Denniss]

Thank you for the write-up Hannes.

Version 04 adds an IANA consideration section as promised. In reviewing the
IANA considerations, I added a normative reference to RFC7595 where private
use of the URI namespace is defined (and which were compliant with already
– but I made that more clear as well).

RFC6819 is now informatively referenced.

I went over the ID-nits checklist and cleaned up some of the less stable
informative references based on that. I also did a general editing pass to
clean up some of the rough edges.

I believe all 3 points are addressed now.


On Tue, Oct 11, 2016 at 12:06 PM, John Bradley  wrote:

> A updated draft with the IANA section and comments addressed will be out
> shortly.
>
> We will try to get it out today or early tomorrow.
>
> John B.
>
>
> On Oct 11, 2016, at 3:33 PM, Brian Campbell 
> wrote:
>
> I believe there are a few small WGLC comments outstanding too.
>
> On Mon, Oct 10, 2016 at 4:30 AM, Hannes Tschofenig <
> hannes.tschofe...@gmx.net> wrote:
>
>> Hi all,
>>
>> Here is the shepherd writeup for the native apps document:
>> https://github.com/hannestschofenig/tschofenig-ids/blob/
>> master/shepherd-writeups/Writeup_OAuth_NativeApps.txt
>>
>> There are only a few minor things missing:
>>
>> 1) I haven't received a response from William on my IPR confirmation
>> question (as far as I can tell):
>> https://www.ietf.org/mail-archive/web/oauth/current/msg16672.html
>>
>> 2) The document lacks an IANA Considerations section. Please add one and
>> indicate that there are no actions for IANA.
>>
>> 3) There is an unused reference in the document, namely RFC 6819
>>
>> Ciao
>> 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
>
>
>
> ___
> 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 2.0 for Native Apps: IPR Confirmation

[William Denniss]

I know of no IPR disclosures for this document.



I have none to make.


- William Denniss



On Mon, Sep 19, 2016 at 8:49 AM, <ve7...@ve7jtb.com> wrote:

> I know of no IPR disclosures for this document.
>
>
>
> I have none to make.
>
>
>
> John B.
>
>
>
> Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for
> Windows 10
>
>
>
> *From: *Hannes Tschofenig <hannes.tschofe...@gmx.net>
> *Sent: *September 19, 2016 6:07 AM
> *To: *oauth@ietf.org
> *Subject: *[OAUTH-WG] OAuth 2.0 for Native Apps: IPR Confirmation
>
>
>
> Hi William, Hi John,
>
>
>
> I am working on the shepherd writeup for the Native Apps document:
>
> https://tools.ietf.org/html/draft-ietf-oauth-native-apps-03
>
>
>
> One item in the template requires me to indicate whether each document
>
> author has confirmed that any and all appropriate IPR disclosures
>
> required for full conformance with the provisions of BCP 78 and BCP 79
>
> have already been filed.
>
>
>
> Could you please confirm?
>
>
>
> Ciao
>
> 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
>
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Mix-Up and CnP/ Code injection

[William Denniss]

I'm inclined to think that Nat's comment is right: "As I look at it more
and more, it started to look like the problem of accepting tainted values
without message authentication. To fix the root cause, we would have to
authenticate response. ID Token was designed to also serve as a solution
anticipating it."

Even if we workaround the current issue with more unbound plain text
params, will it solve the *next* issue?  Personally I'm not convinced.

I also wonder at what level of risk is the right solution "code id_token",
which the researchers note *will* mitigate the attacks (when implemented
correctly).

If we absolutely must solve this without "id_token", I know John has a few
ideas for lightweight binding of the request & response by hashing the
request URL and some config. I wonder if a "lightweight crypto" approach is
superior to "more unbound params" as the best non-id_token option.

On Sat, Apr 30, 2016 at 10:36 PM, Nat Sakimura  wrote:

> It actually depends on what risk level the transaction is at. For low risk
> transactions, just having separate redirection endpoint may be adequate. On
> the other hand, I can easily think of an attack that replaces iss on the
> authz response making the control invalid posing questions on whether it is
> worth introducing it.
> On Sun, May 1, 2016 at 14:21 Justin Richer  wrote:
>
>> I agree that we’re getting dangerously close to recommending signed
>> assertions at every step of the process, thereby bypassing HTTP. This was
>> the same mistake that WS-* and SOAP made, let’s not repeat it if we can.
>>
>>  — Justin
>>
>> On Apr 30, 2016, at 10:57 AM, Torsten Lodderstedt <
>> tors...@lodderstedt.net> wrote:
>>
>> Hi Nat,
>>
>> sure, one could also authenticate and cryptographically protect the
>> redirect response. Leveraging OIDC concepts is an idea worth considering
>> but they should be adopted to the OAuth philosophy. The id token as used in
>> the hybrid flows mixes an identity assertion with elements of transport
>> security measures. A OAuth AS does not provide identity data to clients, so
>> we only need the transport security part.
>>
>> I personally would prefer a OAuth response object (similar to request
>> object you have proposed) over the id token. Such a response object could
>> contain (and directly protect) state, code and other response values. I
>> consider this the more elegant design and it is easier to implement then
>> having detached signatures over hash values of codes or access tokens.
>> Moreover, it would allow to encrypt the response as well.
>>
>> Generally, our threat analysis so far does not have provided
>> justification for cryptographically protected redirect responses. All
>> proposals currently on the table stop mix up and code injection using
>> simpler mechanisms.
>>
>> I think OAuth 2.0 is a huge success due to its balance of versatility,
>> security and _simplicity_. We definitely need to keep it secure, but we
>> should also keep it as simple as possible.
>>
>> kind regards,
>> Torsten.
>> Am 29.04.2016 um 10:08 schrieb Nat Sakimura:
>>
>> As I look at it more and more, it started to look like the problem of
>> accepting tainted values without message authentication. To fix the root
>> cause, we would have to authenticate response. ID Token was designed to
>> also serve as a solution anticipating it.
>>
>> Any concrete ideas?
>>
>> On Sat, Apr 23, 2016 at 04:47 Torsten Lodderstedt <
>> tors...@lodderstedt.net> wrote:
>>
>>> Hi all,
>>>
>>> discussion about Mix-Up and CnP seems to have stopped after the session
>>> in BA - at least in the OAuth WG. There is a discussion about
>>> mitigations in OpenId Connect going on at the OpenId Connect mailing
>>> list.
>>>
>>> I'm very much interested to find a solution within the OAuth realm as
>>> I'm not interested to either implement two solutions (for OpenId Connect
>>> and OAuth) or adopt a OpenId-specific solution to OAuth (use id! tokens
>>> in the front channel). I therefore would like to see progress and
>>> propose to continue the discussion regarding mitigations for both
>>> threats.
>>>
>>> https://tools.ietf.org/html/draft-ietf-oauth-mix-up-mitigation-00
>>> proposes reasonable mitigations for both attacks. There are alternatives
>>> as well:
>>> - mix up:
>>> -- AS specific redirect uris
>>> -- Meta data/turi
>>> (https://tools.ietf.org/html/draft-sakimura-oauth-meta-07#section-5)
>>> - CnP:
>>> -- use of the nonce parameter (as a distinct mitigation beside state for
>>> counter XSRF)
>>>
>>> Anyone having an opinion?
>>>
>>> best regards,
>>> Torsten.
>>>
>>> ___
>>> 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

Re: [OAUTH-WG] OAuth 2.1

[William Denniss]

Fair points. I also think this is an area where good online documentation,
and books like *OAuth 2 in Action* can help, and possibly help a lot sooner.

On Thu, Apr 7, 2016 at 4:15 PM, Adam Lewis  wrote:

> +1
>
> I will not comment on the timeline for this, but I will passionately
> endorse the need for an OAuth 2.1 spec.
>
> Speaking as somebody who now has spent years advocating for, and building
> out public safety / first responder architectures built on an OAuth 2.0
> architecture, I can say 2 things with conviction:
>
> The good: OAuth 2.0 has enabled incredible use cases for us, and it is a
> gift that keeps on giving, the new WG efforts around POP and token exchange
> are solving even more use cases for us.  This is hands down one of the best
> WGs I've known, and the work done here is nothing short of awesome.
>
> The bad: I have yet to meet anybody outside of the WG that really
> understands OAuth 2.0.  I mean "really" understands it.  (to this day, I
> still think it is only because of the good graces of others in this WG like
> John and Justin that I understand it with the depth that I do).  People
> talk about it at high levels, they talk about tokens, but still don't get
> what it is trying to solve nor how to securely deploy it. 99% of the people
> I meet still don't get the difference between authentication and delegated
> authorization.  I have dedicated massive amounts of cycles trying to
> educate my own community (and anybody else I meet for that matter).  I
> personally found the core RFC very hard to digest, and now I need to refer
> to N more, many of which should be folded into a new 2.1 core spec.  All
> this given, It is no wonder there are so many insecure implementations of
> it.
>
> So here's to OAuth 2.1 :-)
>
> -adam
>
> On Thu, Apr 7, 2016 at 1:56 PM, Hardt, Dick  wrote:
>
>> I think there are already years of implementation and experience since 2.0
>>
>> If we wait until all the outstanding issues and new features have had
>> implementations and experience, we will never do a 2.1 as there continues
>> to be new things.
>>
>> I would suggest a 2.1 be a clean, simple document of the core spec in one
>> document that includes the security and implementation recommendations.
>>
>> Alternative title: OAuth, The Good Parts. :)
>>
>> — Dick
>>
>>
>>
>>
>> On 4/7/16, 3:25 PM, someone claiming to be "OAuth on behalf of Mike
>> Jones" 
>> wrote:
>>
>> Yes - an intentionally conservative, implementation- and
>> experience-driven path.
>>
>> Revising OAuth 2.0 is a *big deal*.  We shouldn't even be talking about
>> it until we've completed steps 1-5 below - *including* the "iterate" step,
>> as necessary.  If we get this wrong, we'll fragment OAuth, which is a
>> terrible and irresponsible outcome we should consciously avoid at all costs.
>>
>> In particular, we should not recharter for an OAuth 2.1 until we already
>> know what will be in it and know from deployment experience that it's the
>> right stuff.
>>
>> -- Mike
>>
>> -Original Message-
>> From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net]
>> Sent: Thursday, April 7, 2016 3:16 PM
>> To: Mike Jones 
>> Cc: Samuel Erdtman ; Anthony Nadalin <
>> tony...@microsoft.com>; oauth@ietf.org
>> Subject: Re: [OAUTH-WG] OAuth 2.1
>>
>> Hi Mike,
>>
>> in my opinion, you described a possible path towards 2.1. Would you agree?
>>
>> best regards,
>> Torsten.
>>
>> > Am 07.04.2016 um 13:38 schrieb Mike Jones > >:
>> >
>> > I am strongly against creating a 2.1 spec until we have at least a year
>> of deployment experience with the contents we're adding to 2.0, so as not
>> to fragment the OAuth marketplace.
>> >
>> > I think we should:
>> > 1.  Continue working on new security mitigations in new drafts (such
>> > as mix-up-mitigation, etc.) that add features to use with 2.0 2.
>> > Continue working on PoP specs (such as pop-key-distribution, etc.)
>> > that add features to use with 2.0 3.  Continue working on other new
>> > specs (such as discovery, resource-indicators, etc.) that add features
>> > to use with 2.0 4.  Learn from deployment experience with all of them
>> > 5.  Iterate if the deployment experience tells us that we need to
>> >
>> > Only after we believe we have all the features right and we know that
>> they work together well should we consider creating a 2.1.  If we rush to a
>> 2.1 and get it wrong, we'll lose developers' trust and we'll never get it
>> back.
>> >
>> >-- Mike
>> >
>> > -Original Message-
>> > From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Samuel
>> > Erdtman
>> > Sent: Thursday, April 7, 2016 12:48 PM
>> > To: Anthony Nadalin 
>> > Cc: oauth@ietf.org
>> > Subject: Re: [OAUTH-WG] OAuth 2.1
>> >
>> > +1 on a 2.1 

Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery

[William Denniss]

I support the document moving forward, and agree with the proposal to
rename it to "OAuth 2.0 Authorization Server Discovery Metadata".

Personally I was fine with re-using 'openid-configuration' for
compatibility, but I suppose it's not a big burden for everyone who is
already using that to setup an alias, as long as the AS metadata and OIDC
discovery specs remain compatible which I expect they will.

On Thu, Mar 10, 2016 at 5:04 AM, Roland Hedberg 
wrote:

> I support this document being moved forward with these two changes:
>
> - change name to “OAuth 2.0 Authorization Server Discovery Metadata” as
> proposed by Brian and
> - use the URI path suffix ’oauth-authorization-server’ instead of
> ’openid-configuration’ as proposed by Justin.
>
> > 18 feb 2016 kl. 14:40 skrev Hannes Tschofenig  >:
> >
> > Hi all,
> >
> > This is a Last Call for comments on the  OAuth 2.0 Discovery
> specification:
> > https://tools.ietf.org/html/draft-ietf-oauth-discovery-01
> >
> > Since this document was only adopted recently we are running this last
> > call for **3 weeks**.
> >
> > Please have your comments in no later than March 10th.
> >
> > Ciao
> > Hannes & Derek
> >
> > ___
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
>
> — Roland
>
> ”Everybody should be quiet near a little stream and listen."
> From ’Open House for Butterflies’ by Ruth Krauss
>
>
> ___
> 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] 2nd Call for Adoption: Authentication Method Reference Values

[William Denniss]

+1 to adopt.

My previous concerns of this draft have been addressed, and I am supportive
of having an IANA registry of amr values.

On Thu, Feb 18, 2016 at 5:09 AM, Hannes Tschofenig <
hannes.tschofe...@gmx.net> wrote:

> In response to my message to the list regarding the initial call for
> adoption of the Authentication Method Reference Values draft, see
> https://www.ietf.org/mail-archive/web/oauth/current/msg15694.html, Mike
> submitted an updated version of the document to take raised concerns
> into account. Several working group participants responded positively to
> the new version.
>
> We would therefore like to issue a 2nd call for adoption of the recently
> submitted version -05:
> https://tools.ietf.org/html/draft-jones-oauth-amr-values-05
>
> Please let us know by March 3rd whether you accept / object to the
> adoption of this document as a starting point for work in the OAuth
> working group.
>
> Ciao
> Hannes & Derek
>
>
> ___
> 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] Call for Adoption: Stateless Client Identifier for OAuth 2

[William Denniss]

+1 to adopt.

I don't think we're planning to use this, but it looks useful and doesn't
harm interoperability so I support it.

On Sat, Feb 6, 2016 at 3:43 AM, Torsten Lodderstedt  wrote:

> +1
>
>
> Am 04.02.2016 um 17:37 schrieb John Bradley:
>
>> I support it.
>>
>> I have always thought of this as informational.  It is not the only way
>> to do it, and has no real interoperability impact.
>>
>> John B.
>>
>>> On Feb 4, 2016, at 3:29 AM, Mike Jones 
>>> wrote:
>>>
>>> I support adoption of this document by the working group as either an
>>> experimental or information specification.
>>>
>>> -- Mike
>>>
>>> -Original Message-
>>> From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Hannes
>>> Tschofenig
>>> Sent: Tuesday, January 19, 2016 4:05 AM
>>> To: oauth@ietf.org
>>> Subject: [OAUTH-WG] Call for Adoption: Stateless Client Identifier for
>>> OAuth 2
>>>
>>> Hi all,
>>>
>>> this is the call for adoption of Stateless Client Identifier for OAuth
>>> 2, see
>>> https://tools.ietf.org/html/draft-bradley-oauth-stateless-client-id-02
>>>
>>> Please let us know by Feb 2nd whether you accept / object to the
>>> adoption of this document as a starting point for work in the OAuth working
>>> group.
>>>
>>> Ciao
>>> Hannes & Derek
>>>
>>>
>>> ___
>>> 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] OAuth 2.0 for Native Apps: Call for Adoption Finalized

[William Denniss]

Thank you everyone for your support, and adoption of this document!

This spec doesn't modify the OAuth 2.0 protocol, rather it provides a set
of technical guidelines for implementing OAuth 2.0 for native apps in a
secure and usable way. The intent is a document that has the technical
approval of this working group, and the IETF as a whole, as per RFC1818.
Based on this, I believe "Best Current Practice" is indeed the correct
designation for this document.

For example, many implementations don't allow redirection URIs for
non-"https" schemes, though RFC6749 doesn't have this restriction. Our BCP
documents how to allow these schemes in redirect URIs safely for native
apps. The advice is based on our experience supporting native clients in
this way for several years.

In X years, if the mobile landscape has changed, I suspect we might revise
the document to point to the new best practices of the time.
BCP-designation helps with this by giving us a stable reference for the
practice of using standards-compliant OAuth with native apps.


On Fri, Feb 5, 2016 at 8:13 AM, John Bradley  wrote:

> The chairs approved this as a working group document.
>
> The initial version I posted is marked as an intended status as a "Best
> Current Practice”
>
> The advantage of a BCP is that it can be updated to include new
> information as things change.
>
> The spec has no extensions to OAuth 2 or MUST’s to profile it.
>
> Like the TLS BCP it provides implementation advice for developers to
> safely use the “Standards Track” specifications.
>
> If that is the wrong intended Category it can be changed by the WG chairs
> at any time.
>
> Thanks for supporting the document.  I hope that we can expand it with
> more specific advice for developers on native platforms
> beyond just iOS and Android.   However what we can do will depend on
> people with experience in other platforms contributing.
>
> Regards
> John B.
>
>
> On Feb 5, 2016, at 12:10 PM, Adam Lewis 
> wrote:
>
> +1 that it should be Informational.
>
> Also, I never got to respond to the original request, but I am heavily in
> favor of this draft. I talk with a lot of native app developers who are
> clueless about how to implement OAuth.  The core RFC is very web app
> oriented.  I look forward to having a more profiled RFC to point them to :-)
>
> adam
>
> On Thu, Feb 4, 2016 at 7:13 PM, Justin Richer  wrote:
>
>> I’d like to note that when Tony brought up it being Experimental on the
>> list, several of us (myself included) pointed out that Informational is the
>> correct designation for this specification.
>>
>>  — Justin
>>
>> > On Feb 4, 2016, at 2:18 PM, Hannes Tschofenig <
>> hannes.tschofe...@gmx.net> wrote:
>> >
>> > Hi all,
>> >
>> > On January 19th I posted a call for adoption of the OAuth 2.0 for Native
>> > Apps specification, see
>> > http://www.ietf.org/mail-archive/web/oauth/current/msg15400.html
>> >
>> > There was very positive feedback during the Yokohama IETF meeting to
>> > work on this document in the OAuth working group. More than 10 persons
>> > responded positively to the call on the mailing list as well.
>> >
>> > Several persons provided additional input for content changes during the
>> > call and here are the relevant links:
>> > http://www.ietf.org/mail-archive/web/oauth/current/msg15434.html
>> > http://www.ietf.org/mail-archive/web/oauth/current/msg15435.html
>> > http://www.ietf.org/mail-archive/web/oauth/current/msg15438.html
>> >
>> > Tony also noted that this document should become an Experimental RFC
>> > rather than a Standards Track RFC. The chairs will consult with the
>> > Security Area directors on this issue.
>> >
>> > To conclude, based on the call  will
>> > become the starting point for work in OAuth. Please submit the document
>> > as draft-ietf-oauth-native-apps-00.txt.
>> >
>> > Ciao
>> > Hannes & Derek
>> >
>> >
>> >
>> > ___
>> > 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 mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Advertise PKCE support in OAuth 2.0 Discovery (draft-jones-oauth-discovery-00)

[William Denniss]

We are now live with this change:

https://accounts.google.com/.well-known/openid-configuration

I'm glad we all reached a consensus on how this param should work, and what
it should be called, and thank you Mike for revising the draft! My ask now
is that we don't revisit this decision, unless for extremely good reasons,
as we don't want to break clients who will start using this.

On Mon, Jan 25, 2016 at 4:08 PM, William Denniss <wdenn...@google.com>
wrote:

> Thanks Mike, looking forward to the update. I reviewed the other thread.
>
> On Mon, Jan 25, 2016 at 2:49 PM, Mike Jones <michael.jo...@microsoft.com>
> wrote:
>
>> I'll add it to the discovery draft in the next day or so.  Also, please
>> see my questions in the message "[OAUTH-WG] Discovery document updates
>> planned". I was waiting for that feedback before doing the update.
>>
>> Thanks,
>> -- Mike
>> --
>> From: William Denniss <wdenn...@google.com>
>> Sent: ‎1/‎25/‎2016 2:29 PM
>> To: John Bradley <ve7...@ve7jtb.com>
>> Cc: Nat Sakimura <sakim...@gmail.com>; oauth@ietf.org; Mike Jones
>> <michael.jo...@microsoft.com>
>> Subject: Re: [OAUTH-WG] Advertise PKCE support in OAuth 2.0 Discovery
>> (draft-jones-oauth-discovery-00)
>>
>> OK great! It seems that we have consensus on this. So this is what we
>> plan to add to our discovery doc, based on this discussion:
>>
>> "code_challenge_methods_supported": ["plain","S256"]
>>
>> What are the next steps? Can we we add it to
>> https://tools.ietf.org/html/draft-jones-oauth-discovery directly? I see
>> that the IANA registry created by that draft is "Specification
>> Required", but PKCE is already an RFC without this param being registered.
>>
>>
>> On Mon, Jan 25, 2016 at 2:11 PM, John Bradley <ve7...@ve7jtb.com> wrote:
>>
>>> Yes sorry.   code_challenge_method is the query parameter so
>>> code_challenge_methods_supported
>>>
>>>
>>> On Jan 25, 2016, at 6:12 PM, William Denniss <wdenn...@google.com>
>>> wrote:
>>>
>>>
>>>
>>> On Thu, Jan 21, 2016 at 6:17 AM, John Bradley <ve7...@ve7jtb.com> wrote:
>>>
>>>> The code_challenge and code_challenge_method parameter names predate
>>>> calling the spec PKCE.
>>>>
>>>> Given that some of us deployed early versions of PKCE in products and
>>>> opensource to mitigate the problem before the spec was completed we decided
>>>> not to rename the parameter names from code_verifier_method to
>>>> pkce_verifier_method.
>>>>
>>>> For consistency we should stick with code_verifier_methods_supported in
>>>> discovery.
>>>>
>>>
>>> To clarify, did you mean "code_challenge_methods_supported"?  That is,
>>> building on the param name "code_challenge_method" from Section 4.3
>>> <https://tools.ietf.org/html/rfc7636#section-4.3>?
>>>
>>>
>>>>
>>>> John B.
>>>>
>>>> On Jan 21, 2016, at 3:12 AM, William Denniss <wdenn...@google.com>
>>>> wrote:
>>>>
>>>> "code_challenge_methods_supported" definitely works for me.
>>>>
>>>> Any objections to moving forward with that? I would like to update our
>>>> discovery doc shortly.
>>>>
>>>> On Thu, Jan 21, 2016 at 1:37 PM, Nat Sakimura <sakim...@gmail.com>
>>>> wrote:
>>>>
>>>>> Ah, OK. That's actually reasonable.
>>>>>
>>>>> 2016年1月21日(木) 9:31 nov matake <mat...@gmail.com>:
>>>>>
>>>>>> I prefer “code_challenge_methods_supported”, since the registered
>>>>>> parameter name is “code_challenge_method”, not “pkce_method".
>>>>>>
>>>>>> On Jan 19, 2016, at 11:58, William Denniss <wdenn...@google.com>
>>>>>> wrote:
>>>>>>
>>>>>> Seems like we agree this should be added. How should it look?
>>>>>>
>>>>>> Two ideas:
>>>>>>
>>>>>> "code_challenge_methods_supported": ["plain", "S256"]
>>>>>>
>>>>>> or
>>>>>>
>>>>>> "pkce_methods_supported": ["plain", "S256"]
>>>>>>
>>>>>>
>>>>>>
>&g

Re: [OAUTH-WG] Discovery document updates planned

[William Denniss]

On Thu, Jan 21, 2016 at 10:37 PM, Mike Jones 
wrote:

> Tomorrow I plan to apply updates to the OAuth Discovery document that have
> been requested since the -00 version was published.  Updates on my list to
> make are:
>
> ·   Adding an equivalent of token_endpoint_auth_methods_supported for
> the revocation endpoint
>
i.e. revocation_endpoint_auth_methods_supported ?

·   Adding an equivalent of token_endpoint_auth_methods_supported for
> the introspection endpoint
>
i.e.  introspection_endpoint_auth_methods_supported ?


> ·   Adding code_challenge_methods_supported
>
> LGTM.


>
>
> Did I miss capturing any metadata values that it makes sense to add at
> this point?
>
>
>
>   Thanks all,
>
>   -- Mike
>

Looks good to me.


>
> ___
> 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] Advertise PKCE support in OAuth 2.0 Discovery (draft-jones-oauth-discovery-00)

[William Denniss]

OK great! It seems that we have consensus on this. So this is what we plan
to add to our discovery doc, based on this discussion:

"code_challenge_methods_supported": ["plain","S256"]

What are the next steps? Can we we add it to
https://tools.ietf.org/html/draft-jones-oauth-discovery directly? I see
that the IANA registry created by that draft is "Specification Required",
but PKCE is already an RFC without this param being registered.


On Mon, Jan 25, 2016 at 2:11 PM, John Bradley <ve7...@ve7jtb.com> wrote:

> Yes sorry.   code_challenge_method is the query parameter so
> code_challenge_methods_supported
>
>
> On Jan 25, 2016, at 6:12 PM, William Denniss <wdenn...@google.com> wrote:
>
>
>
> On Thu, Jan 21, 2016 at 6:17 AM, John Bradley <ve7...@ve7jtb.com> wrote:
>
>> The code_challenge and code_challenge_method parameter names predate
>> calling the spec PKCE.
>>
>> Given that some of us deployed early versions of PKCE in products and
>> opensource to mitigate the problem before the spec was completed we decided
>> not to rename the parameter names from code_verifier_method to
>> pkce_verifier_method.
>>
>> For consistency we should stick with code_verifier_methods_supported in
>> discovery.
>>
>
> To clarify, did you mean "code_challenge_methods_supported"?  That is,
> building on the param name "code_challenge_method" from Section 4.3
> <https://tools.ietf.org/html/rfc7636#section-4.3>?
>
>
>>
>> John B.
>>
>> On Jan 21, 2016, at 3:12 AM, William Denniss <wdenn...@google.com> wrote:
>>
>> "code_challenge_methods_supported" definitely works for me.
>>
>> Any objections to moving forward with that? I would like to update our
>> discovery doc shortly.
>>
>> On Thu, Jan 21, 2016 at 1:37 PM, Nat Sakimura <sakim...@gmail.com> wrote:
>>
>>> Ah, OK. That's actually reasonable.
>>>
>>> 2016年1月21日(木) 9:31 nov matake <mat...@gmail.com>:
>>>
>>>> I prefer “code_challenge_methods_supported”, since the registered
>>>> parameter name is “code_challenge_method”, not “pkce_method".
>>>>
>>>> On Jan 19, 2016, at 11:58, William Denniss <wdenn...@google.com> wrote:
>>>>
>>>> Seems like we agree this should be added. How should it look?
>>>>
>>>> Two ideas:
>>>>
>>>> "code_challenge_methods_supported": ["plain", "S256"]
>>>>
>>>> or
>>>>
>>>> "pkce_methods_supported": ["plain", "S256"]
>>>>
>>>>
>>>>
>>>> On Wed, Jan 6, 2016 at 9:59 AM, Torsten Lodderstedt <
>>>> tors...@lodderstedt.net> wrote:
>>>>
>>>>> +1
>>>>>
>>>>>
>>>>> Am 06.01.2016 um 18:25 schrieb William Denniss:
>>>>>
>>>>> +1
>>>>>
>>>>> On Wed, Jan 6, 2016 at 6:40 AM, John Bradley <ve7...@ve7jtb.com>
>>>>> wrote:
>>>>>
>>>>>> Good point.  Now that PKCE is a RFC we should add it to discovery.
>>>>>>
>>>>>> John B.
>>>>>> > On Jan 6, 2016, at 9:29 AM, Vladimir Dzhuvinov <
>>>>>> vladi...@connect2id.com> wrote:
>>>>>> >
>>>>>> > I just noticed PKCE support is missing from the discovery metadata.
>>>>>> >
>>>>>> > Is it a good idea to add it?
>>>>>> >
>>>>>> > Cheers,
>>>>>> >
>>>>>> > Vladimir
>>>>>> >
>>>>>> > --
>>>>>> > Vladimir Dzhuvinov
>>>>>> >
>>>>>> >
>>>>>> > ___
>>>>>> > 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 
>>>>> 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
>>>>
>>>
>> ___
>> 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] Google's OAuth endpoints now fully support PKCE (RFC7636)

[William Denniss]

Awesome! Great to hear you've implemented it too :)

I added client-side support this weekend into an iOS client that I'm
writing, didn't take long at all.

On Tue, Jan 19, 2016 at 8:02 AM, Vladimir Dzhuvinov <vladi...@connect2id.com
> wrote:

> This is good news William! I hope more developers will become aware of
> PKCE through its adoption by Google. Right now there's virtually zero
> awareness about this option among devs.
>
> Coincidentally we also put support for PKCE in the Nimbus OAuth/OIDC SDK
> this week. Regarding errors we practice what Nat suggested - i.e. we don't
> detail the exact cause of the error, but in the "error_description" field
> we list all possible causes that a client dev should check - invalid code,
> redirect_uri mismatch, bad pkce challenge, etc.
>
> Cheers,
>
> Vladimir
>
> On 19/01/16 07:46, William Denniss wrote:
>
> This month we rolled out full PKCE (RFC7636) support on our OAuth endpoints.
>
> We'd previously implemented an earlier draft but were not conformant to the
> final spec when it was published – now we are. Both "plain" and "S256"
> transforms are supported. As always, get the latest endpoints from our
> discovery 
> document:https://accounts.google.com/.well-known/openid-configuration
>
> If you give it a spin, let me know how you go! The team monitors the Stack
> Overflow google-oauth<http://stackoverflow.com/questions/tagged/google-oauth> 
> <http://stackoverflow.com/questions/tagged/google-oauth> tag too, for any
> implementation questions.
>
> I'm keen to know what we should be putting in our discovery doc to declare
> PKCE support (see the thread "Advertise PKCE support in OAuth 2.0
> Discovery"), hope we can agree on that soon.
>
> One implementation detail not covered in the spec: we error if you
> send code_verifier to the token endpoint when exchanging a code that was
> issued without a code_challenge being present. The assumption being that if
> you are sending code_verifier on the token exchange, you are using PKCE and
> should have sent code_challenge on the authorization request, so something
> is amiss.
>
> William
>
>
>
>
> ___
> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth
>
>
> --
> Vladimir Dzhuvinov
>
>
> ___
> 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 Device Flow

[William Denniss]

Google has additional documentation here:
https://developers.google.com/identity/protocols/OAuth2ForDevices

The implementation mostly follows the original draft, but there are a few
differences. Also we've learnt a lot about the security and usability
implications of this flow along the way, which would be good to document.

On Thu, Nov 5, 2015 at 9:44 AM, Hannes Tschofenig  wrote:

> FYI: A couple of us got together and re-published an old, expired draft
> about the OAuth Device Flow.
>
> Here is the document:
> https://tools.ietf.org/html/draft-denniss-oauth-device-flow-00
>
> For the -00 version we tired to keep it inline with what has been
> available with draft-recordon-oauth-v2-device-00. In upcoming versions
> of this document we would like to capture existing deployment.
>
> Here are two deployment examples that are reasonably well described:
>
> - Google
> https://developers.google.com/youtube/v3/guides/auth/devices
>
> - Facebook
> https://developers.facebook.com/docs/facebook-login/for-devices
>
> Ciao
> 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] Lifetime of refresh token

[William Denniss]

+1 for John's suggestion.

Why force users to re-authenticate after an arbitrary 30-day window?

On Fri, Aug 28, 2015 at 1:41 PM John Bradley ve7...@ve7jtb.com wrote:

 I would use a 5 min AT and roll the refresh token per
 https://tools.ietf.org/html/rfc6749#page-47 with a 1 month expiry if that
 is what you want for a inactivity timeout after which the user must
 authenticate again.   The user can always revoke the refresh token.

 Rolling the refresh token also has the advantage that if the token leaks
 or is stollen then you will detect the second use of the expired refresh
 token and invalidate both, so the user needs to loggin.

 In general I think rolling the refresh token is a good idea though it is
 not popular, I think it is more secure.

 John B.



 On Aug 28, 2015, at 11:21 AM, Donghwan Kim flowersinthes...@gmail.com
 wrote:

 I'm sorry to introduce a common topic.

 As John has suggested, I'm going to design that

 * An access token should be short lived e.g. 5 minutes (not to hit the AS
 to verify the token or 1 hour (to hit the AS to verify the token). I'm
 inclined to 5 minutes for stateless architecture of RSs.
 * A refresh token should have 1 month of expiration time by default. If it
 turns out that some access token expired, its refresh token should refresh
 the token. Then, so called persistent login can be implemented regardless
 of the form of authentication. Only if it fails for some reason e.g. token
 revocation or inactivity for 1 month, a user is logged out automatically
 and should log in again.
 * A refresh token should be able to be revoked somehow. With 5 minutes
 approach, it will invalidate only the refresh token (Yes the attacker can
 have 5 minutes at most), and with 1 hour approach, it will invalidate the
 refresh token as well as the corresponding access token.

 Thanks,

 -- Donghwan

 On Fri, Aug 28, 2015 at 5:43 PM, Torsten Lodderstedt 
 tors...@lodderstedt.net wrote:

 Refresh tokens are also used by public clients, e.g. native apps. OIDC
 allows to acquire a new id token from a refresh token as well. Note: this
 does not mean a fresh authentication but a refreshed id token containing
 the data of the original authentication transaction.

 Am 24. August 2015 17:08:21 MESZ, schrieb John Bradley ve7...@ve7jtb.com
 :

 I think Nat’s diagram about the problems of doing pseudo authentication
 with OAuth is being taken out of context.

 The refresh token dosen’t expire, it is revoked by the user or system.
 In some cases refresh tokens are automatically revoked if the users session
 to the AS ends.  I think AOL typically revokes refresh tokens when sessions
 terminate.

 OpenID Connect provides a separate id_token with a independent lifetime
 from the refresh token.  A client may keep a refresh token for a much
 longer time than the user has a login session with the AS.

 Refresh tokens are typically used by confidential clients that are using
 a client secret in combination with the refresh token for getting a new
 access token.

 By design access tokens should be short lived as the AS is expected to
 have a way of revoking refresh tokens but not access tokens.
 A access token that dosen't expire , and can’t be revoked is not a good
 idea.

 John B.


 On Aug 24, 2015, at 2:41 AM, Donghwan Kim flowersinthes...@gmail.com
 wrote:

 Hi,

 According to Figure 2 from
 http://tools.ietf.org/html/rfc6749#section-1.5, refresh token can be
 used to refresh an expired access token without requesting resource owner
 to sign in again (uncomfortable experience). However, if it's true, isn't
 it that refresh token might be used to request a new access token even
 years later? and then isn't refresh token the same with access token which
 never expires?

 I intended to use refresh token to implement persistent login by sending
 a refresh request before issued access token expires (expires_in runs out).
 But if refresh token works even if access token expired already, sending a
 refresh request on application start up would be enough.

 So I'm not sure what I'm missing about refresh token as well as how to
 implement persistent login using it (you can regard authentication here
 pseudo-authentication illustrated in
 https://upload.wikimedia.org/wikipedia/commons/3/32/OpenIDvs.Pseudo-AuthenticationusingOAuth.svg).
 What is the lifetime of refresh token?

 Thanks,

 -- Donghwan
 ___
 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] Is it allow to add custom attribute to access token response?

[William Denniss]

You can add additional parameters.

The client MUST ignore unrecognized value names in the response is there
so that other clients who don't understand your parameters will ignore
them. That line basically enables the behavior you wanted (if it said the
client must *error* on unrecognized values, that would be a problem).

It would be best if you tried to name your params to be hardened against
collision with any future extensions to OAuth/OpenID Connect (e.g., adding
a vendor prefix)

On Thu, Aug 20, 2015 at 7:15 AM, Donghwan Kim flowersinthes...@gmail.com
wrote:

 Hi,

 I would like to add a custom property representing the account who just
 authenticated to the access token response for the sake of convenience like
 login request's response. Then, an exchange of request and response will
 look like this:

 POST /tokens HTTP/1.1
 Host: api.example.com
 Content-Type: application/json

 {grant_type:password,username:${username},password:${password}}


 HTTP/1.1 200 OK
 Content-Type: application/json
 Cache-Control: no-store
 Pragma: no-cache

 {
   access_token:${JSON web token},
   token_type:Bearer,
   account: {username:donghwan, ...}
 }


 However http://tools.ietf.org/html/rfc6749#section-5.1 says that

  The client MUST ignore unrecognized value names in the response.

 Does it mean that I shouldn't add such property, 'account'? Though, I saw
 Instagram API adds such custom property to access token response for the
 same purpose from https://instagram.com/developer/authentication/ (Please
 find 'snoopdogg' to see that token response.) If it's not allowed or
 desirable, how should I add such information to the access token response?

 BTW, I have some questions on usage of JSON web token with OAuth. Can I
 post them here? If not, where should I do that?

 Thanks,

 -- Donghawn

 ___
 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] “amr” Values spec updated

[William Denniss]

Fair point. RBA is a fairly common acronym for Risk-Based Authentication,
how about going with rba? Would align with existing mfa, mca
definitions (while also saving 1 character and helping the ambiguity issue).

On Fri, Aug 14, 2015 at 10:44 AM, Mike Jones michael.jo...@microsoft.com
wrote:

 I hear you, but we’re trying to keep the values short for space reasons –
 just like other identifiers in JWTs.  Ultimately, the values aren’t
 meaningful without referring to the spec in the first place, so the place
 to beef up the meaning is in the description in the spec – not in the “amr”
 value.  If you’d like to suggest any edits in that regard, have at it!



 Thanks,

 -- Mike



 *From:* William Denniss [mailto:wdenn...@google.com]
 *Sent:* Friday, August 14, 2015 1:40 PM
 *To:* Mike Jones
 *Cc:* oauth@ietf.org
 *Subject:* Re: [OAUTH-WG] “amr” Values spec updated



 Looking good, thanks for putting this together.



 I wonder if we should say risk_based rather than just risk to avoid
 ambiguity (i.e. that it's not a risky authentication method, rather, it was
 risk-based).  user seems to work well, e.g. user mfa pwd otp tells a
 logical story.







 On Thu, Aug 13, 2015 at 8:43 PM, Mike Jones michael.jo...@microsoft.com
 wrote:

 I’ve updated the Authentication Method Reference Values spec to
 incorporate feedback received from the OAuth working group.  Changes were:

 ·Added the values “mca” (multiple-channel authentication), “risk”
 (risk-based authentication), and “user” (user presence test).

 ·Added citations in the definitions of Windows integrated
 authentication, knowledge-based authentication, risk-based authentication,
 multiple-factor authentication, one-time password, and proof-of-possession.

 ·Alphabetized the values.

 ·Added Tony Nadalin as an author and added acknowledgements.



 The specification is available at:

 ·http://tools.ietf.org/html/draft-jones-oauth-amr-values-01
 https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2ftools.ietf.org%2fhtml%2fdraft-jones-oauth-amr-values-01data=01%7c01%7cMichael.Jones%40microsoft.com%7c1f21f86f4e4a4858dff908d2a4cf71f3%7c72f988bf86f141af91ab2d7cd011db47%7c1sdata=I5MFZbd1BMANLuVeDH24boBVJ1CSwybIg3P1RqTZweU%3d



 An HTML formatted version is also available at:

 ·http://self-issued.info/docs/draft-jones-oauth-amr-values-01.html
 https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fself-issued.info%2fdocs%2fdraft-jones-oauth-amr-values-01.htmldata=01%7c01%7cMichael.Jones%40microsoft.com%7c1f21f86f4e4a4858dff908d2a4cf71f3%7c72f988bf86f141af91ab2d7cd011db47%7c1sdata=rpA2%2fLQGs5mdomEP4xBu7T9V4PWzVi2j8d1VTzPCCZg%3d



 -- Mike



 P.S.  This note was also posted at http://self-issued.info/?p=1437
 https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fself-issued.info%2f%3fp%3d1437data=01%7c01%7cMichael.Jones%40microsoft.com%7c1f21f86f4e4a4858dff908d2a4cf71f3%7c72f988bf86f141af91ab2d7cd011db47%7c1sdata=sv5HbcRW%2bjRbYcd71MRZBcFdks%2froaDqZ%2fqTKOJrJ%2fo%3d
 and as @selfissued
 https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2ftwitter.com%2fselfissueddata=01%7c01%7cMichael.Jones%40microsoft.com%7c1f21f86f4e4a4858dff908d2a4cf71f3%7c72f988bf86f141af91ab2d7cd011db47%7c1sdata=ex43UP5ytuIMsfe6SkABmPAvJbeOpXPbHQbnvixUNcQ%3d
 .


 ___
 OAuth mailing list
 OAuth@ietf.org
 https://www.ietf.org/mailman/listinfo/oauth
 https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2foauthdata=01%7c01%7cMichael.Jones%40microsoft.com%7c1f21f86f4e4a4858dff908d2a4cf71f3%7c72f988bf86f141af91ab2d7cd011db47%7c1sdata=hlMpGbGhXBCYimtMJa9IfEzWSFqXRy3kKHN8Z%2bLxjn0%3d



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

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-spop-14.txt

[William Denniss]

Following up the discussion on today's NAPPS call, I understand why plain
is not presented as the recommended approach in the spec (though it still
has some value over not doing PKCE at all, in that it mitigates against the
current known attack where a rogue app registers the same custom URI scheme
as another), but I feel that after all the back and forth the picture is a
little confusing.

In particular, 4.2 and 4.4.1 include some examples where plain is supported:

4.2
 Clients SHOULD use the S256 transformation.  The plain transformation is
 for compatibility with existing deployments and for constrained
 environments that can't use the S256 transformation.



4.4.1.
 If the client is capable of using S256, it MUST use S256, as S256 is
 Mandatory To Implement (MTI) on the server. Clients are permitted to use
 plain only if they cannot support S256 for some technical reason and
 knows that the server supports plain.


But then 7.2 is very vocal that it MUST NOT be used for new implementations:

7.2
 Because of this, plain SHOULD NOT be used, and exists only
 for compatibility with deployed implementations where the request path
 is already protected.  The plain method MUST NOT be used in
 new implementations.


 What if those new implementations are constrained, as indicated in 4.2 and
4.4.1?


Also, while S256 is clearly indicated as MTI, little is said about plain,
although it's alluded to that it's not MTI in 4.4.1 (and knows that the
server supports plain).

Should we be more explicit upfront that plain is optional for servers to
support, if that's the intention?


On Tue, Jul 7, 2015 at 10:51 PM, William Denniss wdenn...@google.com
wrote:

 t_m works for me, I just think we should have some indication that it's
 the name of the transform. Will you also update where it is referenced in
 the description below Figure 2?



 On Tue, Jul 7, 2015 at 6:28 PM, John Bradley ve7...@ve7jtb.com wrote:

 Thanks, I fixed my finger dyslexia for the next draft.

 I changed it to t_m rather than “t”  I think that is clearer.  If I were
 to do it the other way XML2RFC would have double quotes in the text version.

 John B.

 On Jul 7, 2015, at 9:38 PM, William Denniss wdenn...@google.com wrote:

 In version 14, there's a typo on this line (deso) in Section 7.2:

 `plain method deso not protect`

 Also, in the 1.1 Protocol Flow diagram, regarding the text:

 `+ t(code_verifier), t`

 I wonder if it makes more sense to represent as `+ t(code_verifier), t`
 (note the quotes on the second 't') given that it's a string representation
 of the method that's being sent?


 On Mon, Jul 6, 2015 at 4:05 PM, internet-dra...@ietf.org wrote:


 A New Internet-Draft is available from the on-line Internet-Drafts
 directories.
  This draft is a work item of the Web Authorization Protocol Working
 Group of the IETF.

 Title   : Proof Key for Code Exchange by OAuth Public
 Clients
 Authors : Nat Sakimura
   John Bradley
   Naveen Agarwal
 Filename: draft-ietf-oauth-spop-14.txt
 Pages   : 20
 Date: 2015-07-06

 Abstract:
OAuth 2.0 public clients utilizing the Authorization Code Grant are
susceptible to the authorization code interception attack.  This
specification describes the attack as well as a technique to mitigate
against the threat through the use of Proof Key for Code Exchange
(PKCE, pronounced pixy).


 The IETF datatracker status page for this draft is:
 https://datatracker.ietf.org/doc/draft-ietf-oauth-spop/

 There's also a htmlized version available at:
 https://tools.ietf.org/html/draft-ietf-oauth-spop-14

 A diff from the previous version is available at:
 https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-spop-14


 Please note that it may take a couple of minutes from the time of
 submission
 until the htmlized version and diff are available at tools.ietf.org.

 Internet-Drafts are also available by anonymous FTP at:
 ftp://ftp.ietf.org/internet-drafts/

 ___
 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] I-D Action: draft-ietf-oauth-spop-14.txt

[William Denniss]

t_m works for me, I just think we should have some indication that it's
the name of the transform. Will you also update where it is referenced in
the description below Figure 2?



On Tue, Jul 7, 2015 at 6:28 PM, John Bradley ve7...@ve7jtb.com wrote:

 Thanks, I fixed my finger dyslexia for the next draft.

 I changed it to t_m rather than “t”  I think that is clearer.  If I were
 to do it the other way XML2RFC would have double quotes in the text version.

 John B.

 On Jul 7, 2015, at 9:38 PM, William Denniss wdenn...@google.com wrote:

 In version 14, there's a typo on this line (deso) in Section 7.2:

 `plain method deso not protect`

 Also, in the 1.1 Protocol Flow diagram, regarding the text:

 `+ t(code_verifier), t`

 I wonder if it makes more sense to represent as `+ t(code_verifier), t`
 (note the quotes on the second 't') given that it's a string representation
 of the method that's being sent?


 On Mon, Jul 6, 2015 at 4:05 PM, internet-dra...@ietf.org wrote:


 A New Internet-Draft is available from the on-line Internet-Drafts
 directories.
  This draft is a work item of the Web Authorization Protocol Working
 Group of the IETF.

 Title   : Proof Key for Code Exchange by OAuth Public
 Clients
 Authors : Nat Sakimura
   John Bradley
   Naveen Agarwal
 Filename: draft-ietf-oauth-spop-14.txt
 Pages   : 20
 Date: 2015-07-06

 Abstract:
OAuth 2.0 public clients utilizing the Authorization Code Grant are
susceptible to the authorization code interception attack.  This
specification describes the attack as well as a technique to mitigate
against the threat through the use of Proof Key for Code Exchange
(PKCE, pronounced pixy).


 The IETF datatracker status page for this draft is:
 https://datatracker.ietf.org/doc/draft-ietf-oauth-spop/

 There's also a htmlized version available at:
 https://tools.ietf.org/html/draft-ietf-oauth-spop-14

 A diff from the previous version is available at:
 https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-spop-14


 Please note that it may take a couple of minutes from the time of
 submission
 until the htmlized version and diff are available at tools.ietf.org.

 Internet-Drafts are also available by anonymous FTP at:
 ftp://ftp.ietf.org/internet-drafts/

 ___
 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] draft-ietf-oauth-spop-04: a way of making code_challenge

[William Denniss]

On Thu, Nov 13, 2014 at 6:00 PM, Nat Sakimura sakim...@gmail.com wrote:

 Regarding

  Other problem is the following, using Nat’s slide:
  http://www.slideshare.net/nat_sakimura/1112-spoppresso .
 
  0.Attacker prepares own code_verifier and code_challenge.
  1.replage legitimate challenge with malicious code_challenge.
  5. Attacker can submits own code_verifier.
 
  It may be out of the draft, I think.

 I think this is out of scope.


I agree that this is out of scope.

SPOP is designed to protect an interception of the OAuth code grant which
is a known risk on some mobile platforms. With the S256 transformation it
also protects against eavesdropping of the app-to-app communication channel.




 On Fri Nov 14 2014 at 10:46:07 John Bradley ve7...@ve7jtb.com wrote:

 We have discussed it and that was in fact my original recommendation.
  However I have been convinced that it adds complexity without any real
 improvement in security.

 The reality is that people don't bother with rainbow tables these days.
 They calculate hashes on the fly faster than they can look them up.   If
 you are generating the hashes to find a collision then having fixed text
 that is known to the attacker won't help.

 It is better for people to have more entropy in the code verifier than to
 have a fixed block of text.   I want to avoid people using less bits of
 entropy because they think the hmac is adding something.

 I will come up with some text for the spec, as you are not the only
 person asking that question.

 The other issue is that the term HMAC is scary to developers and we want
 maximum adoption.

 John B.

 Sent from my iPhone

  On Nov 13, 2014, at 3:28 PM, takamichi saito sa...@cs.meiji.ac.jp
 wrote:
 
 
  Hi all,
 
  I appreciate this idea, simple and powerful to achieve proof of
 possession.
  But, I have some questions against the scheme.
  Sorry if these ware already discussed.
 
  I worry about using a hash function in simple way.
  I mean, a simple use of random as code_verifier may cause that
 malicious client can have any code_verifier and code_challenge.
  All combinations of random and its hash can be obtained, it may not be
 risk?
 
  So, we should use:
  S256 code_challenge = BASE64URL(SHA256(code_verifier + “client
 ID”))
  or
  S256 code_challenge = BASE64URL(SHA256(code_verifier + “client ID”
 + “server ID”))
  Where, you know that client ID is client’s unique name.
 
 
  Other problem is the following, using Nat’s slide:
  http://www.slideshare.net/nat_sakimura/1112-spoppresso .
 
  0.Attacker prepares own code_verifier and code_challenge.
  1.replage legitimate challenge with malicious code_challenge.
  5. Attacker can submits own code_verifier.
 
  It may be out of the draft, I think.
 
  Best regards,
 
 
  ;; takamixhi saito
 
  ___
  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