Re: [OAUTH-WG] Proposed OAuth agenda items

[Kepeng Li]

I’d like to add one short agenda item (5 min), to discuss the way forward:
http://datatracker.ietf.org/doc/draft-sakimura-oauth-rjwtprof/

Thanks,

Kind Regards
Kepeng

发件人:  Mike Jones 
日期:  Friday, 10 July, 2015 5:09 am
至:  "oauth@ietf.org" 
主题:  [OAUTH-WG] Proposed OAuth agenda items

I’d like to see us cover the following topics during our meeting in Prague…
 
Issues and Choices for Token Exchange, Brian Campbell and Mike Jones, 30
minutes
 
Next steps to complete the POP documents, 30 minutes?:
draft-ietf-oauth-pop-key-distribution, John Bradley?, 15
minutes?
draft-ietf-oauth-pop-architecture, Phil Hunt?, 10 minutes?
draft-ietf-oauth-proof-of-possession, Mike Jones, 5 minutes
(or less)
 
And if the authors would like to talk about the status of jwsreq,
signed-http-request, etc., I’d welcome that as well.
 
I’m assuming that introspection and spop are far enough along we won’t need
working group time for them?
 
See you in
Prague!
-- Mike
 
___ OAuth mailing list
OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth

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

[OAUTH-WG] OAuth 2.0 Dynamic Client Registration Protocol is now RFC 7591

[Mike Jones]

The OAuth 2.0 Dynamic Client Registration Protocol specification is now RFC 
7591.  I wrote more about this at 
http://self-issued.info/?p=1414 and as 
@selfissued.

Cheers,
-- Mike

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

[OAUTH-WG] RFC 7592 on OAuth 2.0 Dynamic Client Registration Management Protocol

[rfc-editor]

A new Request for Comments is now available in online RFC libraries.


RFC 7592

Title:  OAuth 2.0 Dynamic Client Registration 
Management Protocol 
Author: J. Richer, Ed.,
M. Jones,
J. Bradley,
M. Machulak
Status: Experimental
Stream: IETF
Date:   July 2015
Mailbox:i...@justin.richer.org, 
m...@microsoft.com, 
ve7...@ve7jtb.com,
maciej.machu...@gmail.com
Pages:  18
Characters: 38044
Updates/Obsoletes/SeeAlso:   None

I-D Tag:draft-ietf-oauth-dyn-reg-management-15.txt

URL:https://www.rfc-editor.org/info/rfc7592

DOI:http://dx.doi.org/10.17487/RFC7592

This specification defines methods for management of OAuth 2.0
dynamic client registrations for use cases in which the properties of
a registered client may need to be changed during the lifetime of the
client.  Not all authorization servers supporting dynamic client
registration will support these management methods.

This document is a product of the Web Authorization Protocol Working Group of 
the IETF.


EXPERIMENTAL: This memo defines an Experimental Protocol for the
Internet community.  It does not specify an Internet standard of any
kind. Discussion and suggestions for improvement are requested.
Distribution of this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  https://www.ietf.org/mailman/listinfo/ietf-announce
  https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see https://www.rfc-editor.org/search
For downloading RFCs, see https://www.rfc-editor.org/rfc.html

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-edi...@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC

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

[OAUTH-WG] RFC 7591 on OAuth 2.0 Dynamic Client Registration Protocol

[rfc-editor]

A new Request for Comments is now available in online RFC libraries.


RFC 7591

Title:  OAuth 2.0 Dynamic Client Registration 
Protocol 
Author: J. Richer, Ed.,
M. Jones, 
J. Bradley,
M. Machulak,
P. Hunt
Status: Standards Track
Stream: IETF
Date:   July 2015
Mailbox:i...@justin.richer.org, 
m...@microsoft.com, 
ve7...@ve7jtb.com,
maciej.machu...@gmail.com, 
phil.h...@yahoo.com
Pages:  39
Characters: 87811
Updates/Obsoletes/SeeAlso:   None

I-D Tag:draft-ietf-oauth-dyn-reg-30.txt

URL:https://www.rfc-editor.org/info/rfc7591

DOI:http://dx.doi.org/10.17487/RFC7591

This specification defines mechanisms for dynamically registering
OAuth 2.0 clients with authorization servers.  Registration requests
send a set of desired client metadata values to the authorization
server.  The resulting registration responses return a client
identifier to use at the authorization server and the client metadata
values registered for the client.  The client can then use this
registration information to communicate with the authorization server
using the OAuth 2.0 protocol.  This specification also defines a set
of common client metadata fields and values for clients to use during
registration.

This document is a product of the Web Authorization Protocol Working Group of 
the IETF.

This is now a Proposed Standard.

STANDARDS TRACK: This document specifies an Internet Standards Track
protocol for the Internet community, and requests discussion and suggestions
for improvements.  Please refer to the current edition of the Official
Internet Protocol Standards (https://www.rfc-editor.org/standards) for the 
standardization state and status of this protocol.  Distribution of this 
memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  https://www.ietf.org/mailman/listinfo/ietf-announce
  https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see https://www.rfc-editor.org/search
For downloading RFCs, see https://www.rfc-editor.org/rfc.html

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-edi...@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC

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

[OAUTH-WG] Proposed OAuth agenda items

[Mike Jones]

I'd like to see us cover the following topics during our meeting in Prague...

Issues and Choices for Token Exchange, Brian Campbell and Mike Jones, 30 minutes

Next steps to complete the POP documents, 30 minutes?:
draft-ietf-oauth-pop-key-distribution, John Bradley?, 15 
minutes?
draft-ietf-oauth-pop-architecture, Phil Hunt?, 10 minutes?
draft-ietf-oauth-proof-of-possession, Mike Jones, 5 minutes (or 
less)

And if the authors would like to talk about the status of jwsreq, 
signed-http-request, etc., I'd welcome that as well.

I'm assuming that introspection and spop are far enough along we won't need 
working group time for them?

See you in 
Prague!
-- Mike

___
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

[John Bradley]

I have made some edits to make it consistent.  They are checked into the 
butbucket repo nat and I use, but we can’t update the official draft during the 
freeze before the IETF meeting.

https://bitbucket.org/Nat/oauth-spop

> On Jul 9, 2015, at 3:19 PM, Brian Campbell  wrote:
> 
> I agree with William that it's a little confusing. I get that there's a 
> desire to discourage using "plain" but perhaps the language (especially the 
> MUST NOT in 7.2) should be lightened up just a bit? 
> 
> On Wed, Jul 8, 2015 at 8:22 PM, William Denniss  > wrote:
> 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  > 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  > 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 > > 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, > > 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 d

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

[Brian Campbell]

I agree with William that it's a little confusing. I get that there's a
desire to discourage using "plain" but perhaps the language (especially the
MUST NOT in 7.2) should be lightened up just a bit?

On Wed, Jul 8, 2015 at 8:22 PM, William Denniss  wrote:

> 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 
> 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  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  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,  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