[OAUTH-WG] Review of draft-ietf-oauth-jwsreq-11

[Joel Halpern]

Reviewer: Joel Halpern
Review result: Not Ready

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

.

Document: draft-ietf-oauth-jwsreq-??
Reviewer: Joel Halpern
Review Date: 2017-02-02
IETF LC End Date: 2017-02-13
IESG Telechat date: 2017-02-16

Summary: This document is ready for publication as a Proposed
Standard

Major issues: N/A

Minor issues:
Why is the example if section 4 (and others later on) described
as
"non-normative"?  Is it incomplete?  incorrect?  An example is, by
definition, not a full specification.  The language seems designed to
reduce the value of the example.  I would recommend removing all the
"non-normative" notes from the examples.  They are clearly stated to
be examples. 

Nits/editorial comments: 


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

Re: [OAUTH-WG] OAuth for institutional users

[Denis]

Justin,

Your are making the promotion of your book (OAuth 2 In Action), soon to 
be published.


I browsed through the 23 pages of Chapter 1 that are provided as a free 
download.


I saw the footnote from Manning Publications Co. which states:

"/We welcome reader comments about anything in the manuscript/"

Since Manning Publications Co. asked for it, I hope that you will be 
able to take into consideration some of my comments before this book is 
published.


I will only comment on a few sentences.

1. Page 1: "The application requests authorization from the owner of the 
resource and receivestokens that it can use to access the resource".


Such a model is rather restrictive and does not cover the general case 
where an application is willing to perform an operation on a resource
and where the resource tells to the application which kind of attributes 
need to be presented by the application for that specific operation.
In such a case, the resource owner is not involved in anyway at the time 
of the request. If this restriction remains, this should be clearly stated.


2. Page 10:" To acquire a token, the client first sends the resource 
owner to the authorization server in order to request that the resource 
owner authorize this client".


This sentence is not English. You cannot "send the resource owner to the 
authorization server". This sentence should be rephrased.


3. Page 16: "Even worse, some of the available options in OAuth can be 
taken in the wrong context or not enforced properly, leading to insecure 
implementations.
These kinds of vulnerabilities are discussed at length in the OAuth 
Threat Model Document and the vulnerabilities section of this book 
(chapters 7, 8, 9, and 10)."


Bear in mind that RFC 6819 was issued four years ago (in January 2013). 
Collusions between servers was considered, but collusions between 
clients was omitted,
typically the ABC attack (Alice and Bob Collusion attack). See: 
https://www.ietf.org/mail-archive/web/oauth/current/msg16767.html


You should add some text in section 7.6 to deal with the ABC attack.

4. Page 16: " Ultimately, OAuth 2.0 is a good protocol, but it’s far 
from perfect. We will see its replacement at some point in the future, 
as with all things
in technology, but no real contender has yet emerged as of the writing 
of this book.


I can agree with you that "OAuth 2.0is far from perfect". Can a protocol 
with so many options be a "good protocol" ? Can interoperability be 
achieved ?
I don't think so. You then say: " but no real contender has yet emerged 
as of the writing of this book". I would rather suggest that you delete

" but no real contender has yet emerged as of the writing of this book".

5. Page 17: "OAuth assumes that the resource owner is the one that’s 
controlling the client".


I do hope that it is not the case. The client should only be controlled 
by an end-user or by a local application and no one else.



6. Page 17: " OAuth isn’t defined outside of the HTTP protocol. Since 
OAuth 2.0 with bearer tokens provides no message signatures,
is it not meant to be used outside of HTTPS (HTTP over TLS). Sensitive 
secrets and information are passed over the wire, and
OAuth requires a transport layer mechanism such as TLS to protect these 
secrets".


The HTTPS protocol indeed needs to be used for resource data origin 
authentication and confidentiality protection of the data being exchanged.
However, protecting sensitive secrets and information passed over the 
wire using TLS does not prevent in anyway an ABC attack. TLS binding
does not provide either any extra protection in case of an ABC attack. 
This should be stated since this is an important issue. I really wonder
if you can still say: " OAuth 2.0 is a good protocol". In any case, 
OAuth 2.0 is not a protocol but a framework.


7. Page 18: "OAuth doesn’t define a token format".

How do you want to interoperate if no token format is being defined ? 
IETF RFCs on the standards track are primarily intended to be used to 
address interoperability.


8. Page 18 "In fact, the OAuth protocol explicitly states that the 
content of the token is completely opaque to the client application.


This is even worse. In such a case, the client will be unable to make 
sure that what he got in the token is really what he was asking for: 
nothing more and nothing less.


9. Page 18: " OAuth 2.0 is also not a single protocol. As discussed 
previously, the specification is split into multiple definitions and 
flows, each of which has
its own set of use cases. The core OAuth 2.0 specification has somewhat 
accurately been described as a security protocol generator, because it 
can be used
to design the security architecture for many different use cases. As 
discussed in the previous section, these systems aren’t necessarily 
compatible with each other."


This is indeed a very good description of the current mess.

10. Section 15.2 is not provided. Its title is : *Proof of possession 
(PoP

Re: [OAUTH-WG] Call for adoption: OAuth Security Topics

[Jim Willeke]

+!
I agree this is needed.

--
-jim
Jim Willeke

On Thu, Feb 2, 2017 at 4:33 PM, John Bradley  wrote:

> I am in favour of adoption.
> > On Feb 2, 2017, at 4:09 AM, Hannes Tschofenig 
> wrote:
> >
> > Hi all,
> >
> > this is the call for adoption of the 'OAuth Security Topics' document
> > following the positive call for adoption at the last IETF
> > meeting in Seoul.
> >
> > Here is the document:
> > https://tools.ietf.org/html/draft-lodderstedt-oauth-security-topics-00
> >
> > The intention with this document is to have a place to collect
> > discussions and conclusions around OAuth 2.0 security and to reference
> > the actual solution specifications.
> >
> > Please let us know by Feb 16th 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

Re: [OAUTH-WG] Call for adoption: OAuth Security Topics

[Brian Campbell]

+ 1

On Thu, Feb 2, 2017 at 12:49 PM, Justin Richer  wrote:

> +1, it's a good topic and this document is a good starting point.
>
>  -- Justin
>
> On 2/2/2017 2:09 AM, Hannes Tschofenig wrote:
>
> Hi all,
>
> this is the call for adoption of the 'OAuth Security Topics' document
> following the positive call for adoption at the last IETF
> meeting in Seoul.
>
> Here is the 
> document:https://tools.ietf.org/html/draft-lodderstedt-oauth-security-topics-00
>
> The intention with this document is to have a place to collect
> discussions and conclusions around OAuth 2.0 security and to reference
> the actual solution specifications.
>
> Please let us know by Feb 16th 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 listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth
>
>
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Call for adoption: OAuth Security Topics

[John Bradley]

I am in favour of adoption.
> On Feb 2, 2017, at 4:09 AM, Hannes Tschofenig  
> wrote:
> 
> Hi all,
> 
> this is the call for adoption of the 'OAuth Security Topics' document
> following the positive call for adoption at the last IETF
> meeting in Seoul.
> 
> Here is the document:
> https://tools.ietf.org/html/draft-lodderstedt-oauth-security-topics-00
> 
> The intention with this document is to have a place to collect
> discussions and conclusions around OAuth 2.0 security and to reference
> the actual solution specifications.
> 
> Please let us know by Feb 16th 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



smime.p7s
Description: S/MIME cryptographic signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Call for adoption: OAuth Security Topics

[George Fletcher]

+1 for me too :)

On 2/2/17 2:09 AM, Hannes Tschofenig wrote:

Hi all,

this is the call for adoption of the 'OAuth Security Topics' document
following the positive call for adoption at the last IETF
meeting in Seoul.

Here is the document:
https://tools.ietf.org/html/draft-lodderstedt-oauth-security-topics-00

The intention with this document is to have a place to collect
discussions and conclusions around OAuth 2.0 security and to reference
the actual solution specifications.

Please let us know by Feb 16th 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: OAuth Security Topics

[Justin Richer]

+1, it's a good topic and this document is a good starting point.

 -- Justin


On 2/2/2017 2:09 AM, Hannes Tschofenig wrote:

Hi all,

this is the call for adoption of the 'OAuth Security Topics' document
following the positive call for adoption at the last IETF
meeting in Seoul.

Here is the document:
https://tools.ietf.org/html/draft-lodderstedt-oauth-security-topics-00

The intention with this document is to have a place to collect
discussions and conclusions around OAuth 2.0 security and to reference
the actual solution specifications.

Please let us know by Feb 16th 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] OAuth for institutional users

[Justin Richer]

+1 to Phil's reference to SCIM, and since it looks like you're looking 
to do end user authentication you should look at OpenID Connect:


http://openid.net/connect/

There are a lot of ways to get an authentication protocol based on OAuth 
very, very wrong, and I've covered some of the big ones in an article I 
wrote (with the community's help) a few years ago:


http://oauth.net/articles/authentication/

Furthermore, I've covered the topic in my upcoming book, OAuth 2 In 
Action, which you might find useful:


https://www.manning.com/books/oauth-2-in-action

All said, the space is not as easy as you may think it is at first and 
there are a lot of pitfalls. But the good news is that you're not the 
first to dive in here and there are a lot of really good solutions 
already available.


 -- Justin


On 2/2/2017 10:52 AM, Phil Hunt (IDM) wrote:
You are headed down the road to a very big domain called identity 
management and provisioning.


You might want to look at SCIM (RFC7643, 7644) for a restful api pattern.

SCIM is usually OAuth enabled but the scopes/rights have not yet been 
standardized. There is however some obvious access control patterns 
that apply from the old ldap directory world.


Phil

On Feb 1, 2017, at 6:36 PM, Yunqi Zhang > wrote:



Hi all,

I'm working on a set of API endpoints to allow institutions to manage 
their users and records, and their users to read their own records.


Specifically, each institution will get a {client_id} and a {secret} 
after registering with us, which allows them to create users under 
its institution using [POST https://hostname/users/]. Then the 
institution can also insert records for each user using [POST 
https://hostname/users/:user_id/]. Once a user has been created, 
he/she can read his/her own records using [GET 
https://hostname/users/:user_id/].


In this process, there are two types of authentications I would like 
to achieve, which I'm thinking about using oauth. However, I am super 
new on oauth and have four questions.


Institution authentication (e.g., company FOO will have READ and 
WRITE access to https://hostname/ to create users under its own 
institution, insert records for specific users): (1) Since this part 
of the system will be created and run by the institution, this should 
be a "client credential grant" using {client_id} and {secret} of the 
institution, correct?


End-user authentication (e.g., user John Doe of company FOO will have 
READ access to https://hostname/users/:john_doe_user_id/ to read his 
own personal records): (2) Because this part of the system will 
probably run on the web/mobile app created by company FOO, this 
should be a "resource owner credential grant" using {username}, 
{password} of the specific user, correct?


(3) Because I am allow two types of different authentications, which 
will use two types of different {access_token}s I assume, would that 
be something weird (or hard to build) under the oauth model?


(4) What if the web/mobile app created by a subset of the companies 
already has its own authentication and does not want to create 
another password for each of its users, what should I do? For 
example, company FOO has its own authentication for its web/mobile 
app and does not want to bother creating another password for each of 
its user (i.e., requires only {username}), whereas company BAR would 
like to create another password for each user (i.e., requires 
{username} and {password}). What kind of authentication model should 
I use for a scenario like this?


Thank you very much for your help!

Yunqi
___
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] Call for adoption: OAuth Security Topics

[Mike Jones]

I support adoption.

-- Mike

-Original Message-
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Hannes Tschofenig
Sent: Wednesday, February 1, 2017 11:10 PM
To: oauth@ietf.org
Subject: [OAUTH-WG] Call for adoption: OAuth Security Topics

Hi all,

this is the call for adoption of the 'OAuth Security Topics' document following 
the positive call for adoption at the last IETF meeting in Seoul.

Here is the document:
https://tools.ietf.org/html/draft-lodderstedt-oauth-security-topics-00

The intention with this document is to have a place to collect discussions and 
conclusions around OAuth 2.0 security and to reference the actual solution 
specifications.

Please let us know by Feb 16th 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

Re: [OAUTH-WG] Call for adoption: OAuth Security Topics

[Phil Hunt]

+1

Phil

Oracle Corporation, Identity Cloud Services & Identity Standards
@independentid
www.independentid.com phil.h...@oracle.com 








> On Feb 2, 2017, at 11:11 AM, Anthony Nadalin  wrote:
> 
> I would be in favor of this 
> 
> -Original Message-
> From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Hannes Tschofenig
> Sent: Wednesday, February 1, 2017 11:10 PM
> To: oauth@ietf.org
> Subject: [OAUTH-WG] Call for adoption: OAuth Security Topics
> 
> Hi all,
> 
> this is the call for adoption of the 'OAuth Security Topics' document 
> following the positive call for adoption at the last IETF meeting in Seoul.
> 
> Here is the document:
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-lodderstedt-oauth-security-topics-00&data=02%7C01%7Ctonynad%40microsoft.com%7Cdd2d04df662a4bfe36e508d44b3a84e6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636216162098338101&sdata=9tMjjKtTBQrNVEEpwfMaIH2gTymyADdgjEJnKU4MP6U%3D&reserved=0
> 
> The intention with this document is to have a place to collect discussions 
> and conclusions around OAuth 2.0 security and to reference the actual 
> solution specifications.
> 
> Please let us know by Feb 16th 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: OAuth Security Topics

[Anthony Nadalin]

I would be in favor of this 

-Original Message-
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Hannes Tschofenig
Sent: Wednesday, February 1, 2017 11:10 PM
To: oauth@ietf.org
Subject: [OAUTH-WG] Call for adoption: OAuth Security Topics

Hi all,

this is the call for adoption of the 'OAuth Security Topics' document following 
the positive call for adoption at the last IETF meeting in Seoul.

Here is the document:
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-lodderstedt-oauth-security-topics-00&data=02%7C01%7Ctonynad%40microsoft.com%7Cdd2d04df662a4bfe36e508d44b3a84e6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636216162098338101&sdata=9tMjjKtTBQrNVEEpwfMaIH2gTymyADdgjEJnKU4MP6U%3D&reserved=0

The intention with this document is to have a place to collect discussions and 
conclusions around OAuth 2.0 security and to reference the actual solution 
specifications.

Please let us know by Feb 16th 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

Re: [OAUTH-WG] Alexey Melnikov's Discuss on draft-ietf-oauth-amr-values-05: (with DISCUSS and COMMENT)

[Mike Jones]

I was planning to stay with the characters specified in 6.1 (a) 
https://tools.ietf.org/html/draft-ietf-oauth-amr-values-05#section-6.1:

   a.  require that Authentication Method Reference values being
   registered use only printable ASCII characters excluding double
   quote ('"') and backslash ('\') (the Unicode characters with code
   points U+0021, U+0023 through U+005B, and U+005D through U+007E),

That excludes space.  That's the set taken from RFC 7638, Section 6 
https://tools.ietf.org/html/rfc7638#section-6, which is a very related usage.

Space is excluded because sometimes in OAuth messages, values are represented 
as space-separated strings.

-- Mike

-Original Message-
From: Alexey Melnikov [mailto:aamelni...@fastmail.fm] 
Sent: Thursday, February 2, 2017 7:07 AM
To: Mike Jones ; The IESG 
Cc: draft-ietf-oauth-amr-val...@ietf.org; Hannes Tschofenig 
; oauth-cha...@ietf.org; oauth@ietf.org
Subject: Re: Alexey Melnikov's Discuss on draft-ietf-oauth-amr-values-05: (with 
DISCUSS and COMMENT)

Hi Mike,

On Thu, Feb 2, 2017, at 03:05 PM, Mike Jones wrote:
> I'd be OK limiting the protocol elements to using ASCII characters, if 
> that would be the IESG's preference.

I think that would be much simpler for everybody.

I still want to confirm that spaces are allowed in names. Can you confirm?

> 
> -Original Message-
> From: Alexey Melnikov [mailto:aamelni...@fastmail.fm]
> Sent: Thursday, February 2, 2017 12:06 AM
> To: The IESG 
> Cc: draft-ietf-oauth-amr-val...@ietf.org; Hannes Tschofenig 
> ; oauth-cha...@ietf.org; 
> hannes.tschofe...@gmx.net; oauth@ietf.org
> Subject: Alexey Melnikov's Discuss on draft-ietf-oauth-amr-values-05:
> (with DISCUSS and COMMENT)
> 
> Alexey Melnikov has entered the following ballot position for
> draft-ietf-oauth-amr-values-05: Discuss
> 
> 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-amr-values/
> 
> 
> 
> --
> DISCUSS:
> --
> 
> This is a fine document and I support its publication. However I have 
> a small set of issues that I would like to discuss first.
> 
> Are non ASCII names needed? (This is a protocol element, not a human 
> readable string, so non ASCII is not needed). Are ASCII spaces allowed 
> in names? More generally: what do you call printable character?
> 
> 
> --
> COMMENT:
> --
> 
> In Section 6.1: suggestion to first describe IANA registration policy, 
> then describe restrictions on registered names. Otherwise the current 
> text doesn't flow well.
> 
> I am also agreeing with Stephen's DISCUSS.
> 
> 
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] OAuth for institutional users

[Phil Hunt (IDM)]

You are headed down the road to a very big domain called identity management 
and provisioning. 

You might want to look at SCIM (RFC7643, 7644) for a restful api pattern.

SCIM is usually OAuth enabled but the scopes/rights have not yet been 
standardized. There is however some obvious access control patterns that apply 
from the old ldap directory world.  

Phil

> On Feb 1, 2017, at 6:36 PM, Yunqi Zhang  wrote:
> 
> Hi all,
> 
> I'm working on a set of API endpoints to allow institutions to manage their 
> users and records, and their users to read their own records.
> 
> Specifically, each institution will get a {client_id} and a {secret} after 
> registering with us, which allows them to create users under its institution 
> using [POST https://hostname/users/]. Then the institution can also insert 
> records for each user using [POST https://hostname/users/:user_id/]. Once a 
> user has been created, he/she can read his/her own records using [GET 
> https://hostname/users/:user_id/].
> 
> In this process, there are two types of authentications I would like to 
> achieve, which I'm thinking about using oauth. However, I am super new on 
> oauth and have four questions.
> 
> Institution authentication (e.g., company FOO will have READ and WRITE access 
> to https://hostname/ to create users under its own institution, insert 
> records for specific users): (1) Since this part of the system will be 
> created and run by the institution, this should be a "client credential 
> grant" using {client_id} and {secret} of the institution, correct?
> 
> End-user authentication (e.g., user John Doe of company FOO will have READ 
> access to https://hostname/users/:john_doe_user_id/ to read his own personal 
> records): (2) Because this part of the system will probably run on the 
> web/mobile app created by company FOO, this should be a "resource owner 
> credential grant" using {username}, {password} of the specific user, correct?
> 
> (3) Because I am allow two types of different authentications, which will use 
> two types of different {access_token}s I assume, would that be something 
> weird (or hard to build) under the oauth model?
> 
> (4) What if the web/mobile app created by a subset of the companies already 
> has its own authentication and does not want to create another password for 
> each of its users, what should I do? For example, company FOO has its own 
> authentication for its web/mobile app and does not want to bother creating 
> another password for each of its user (i.e., requires only {username}), 
> whereas company BAR would like to create another password for each user 
> (i.e., requires {username} and {password}). What kind of authentication model 
> should I use for a scenario like this?
> 
> Thank you very much for your help!
> 
> Yunqi
> ___
> 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] Alexey Melnikov's Discuss on draft-ietf-oauth-amr-values-05: (with DISCUSS and COMMENT)

[Alexey Melnikov]

Hi Mike,

On Thu, Feb 2, 2017, at 03:05 PM, Mike Jones wrote:
> I'd be OK limiting the protocol elements to using ASCII characters, if
> that would be the IESG's preference.

I think that would be much simpler for everybody.

I still want to confirm that spaces are allowed in names. Can you
confirm?

> 
> -Original Message-
> From: Alexey Melnikov [mailto:aamelni...@fastmail.fm] 
> Sent: Thursday, February 2, 2017 12:06 AM
> To: The IESG 
> Cc: draft-ietf-oauth-amr-val...@ietf.org; Hannes Tschofenig
> ; oauth-cha...@ietf.org;
> hannes.tschofe...@gmx.net; oauth@ietf.org
> Subject: Alexey Melnikov's Discuss on draft-ietf-oauth-amr-values-05:
> (with DISCUSS and COMMENT)
> 
> Alexey Melnikov has entered the following ballot position for
> draft-ietf-oauth-amr-values-05: Discuss
> 
> 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-amr-values/
> 
> 
> 
> --
> DISCUSS:
> --
> 
> This is a fine document and I support its publication. However I have a
> small set of issues that I would like to discuss first.
> 
> Are non ASCII names needed? (This is a protocol element, not a human
> readable string, so non ASCII is not needed). Are ASCII spaces allowed in
> names? More generally: what do you call printable character?
> 
> 
> --
> COMMENT:
> --
> 
> In Section 6.1: suggestion to first describe IANA registration policy,
> then describe restrictions on registered names. Otherwise the current
> text doesn't flow well.
> 
> I am also agreeing with Stephen's DISCUSS.
> 
> 

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

Re: [OAUTH-WG] Alexey Melnikov's Discuss on draft-ietf-oauth-amr-values-05: (with DISCUSS and COMMENT)

[Mike Jones]

I'd be OK limiting the protocol elements to using ASCII characters, if that 
would be the IESG's preference.

-Original Message-
From: Alexey Melnikov [mailto:aamelni...@fastmail.fm] 
Sent: Thursday, February 2, 2017 12:06 AM
To: The IESG 
Cc: draft-ietf-oauth-amr-val...@ietf.org; Hannes Tschofenig 
; oauth-cha...@ietf.org; hannes.tschofe...@gmx.net; 
oauth@ietf.org
Subject: Alexey Melnikov's Discuss on draft-ietf-oauth-amr-values-05: (with 
DISCUSS and COMMENT)

Alexey Melnikov has entered the following ballot position for
draft-ietf-oauth-amr-values-05: Discuss

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-amr-values/



--
DISCUSS:
--

This is a fine document and I support its publication. However I have a small 
set of issues that I would like to discuss first.

Are non ASCII names needed? (This is a protocol element, not a human readable 
string, so non ASCII is not needed). Are ASCII spaces allowed in names? More 
generally: what do you call printable character?


--
COMMENT:
--

In Section 6.1: suggestion to first describe IANA registration policy, then 
describe restrictions on registered names. Otherwise the current text doesn't 
flow well.

I am also agreeing with Stephen's DISCUSS.


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

Re: [OAUTH-WG] Decentralized OAuth2.0 -- FW: New Version Notification for draft-hardjono-oauth-decentralized-00.txt

[Thomas Hardjono]

What's needed would be (a) contracts servers that can talk to one another, (b) 
addition of pub-keys to some well known endpoints, and (c) some actual 
contracts with actual legal prose :-)

The contract server could be treated as a protected endpoint (e.g. at the AS), 
but since contract agreement is a 2-way handshake we may need to add some new 
message flows.

/thomas/



From: Aaron Parecki [aa...@parecki.com]
Sent: Wednesday, February 01, 2017 7:26 PM
To: Thomas Hardjono
Cc: oauth@ietf.org; oauth-cha...@ietf.org
Subject: Re: [OAUTH-WG] Decentralized OAuth2.0 -- FW: New Version Notification 
for draft-hardjono-oauth-decentralized-00.txt

The introduction sounds great, especially acknowledging the problems due to 
"the predominance of the web single sign-on model as the basis for the user 
interaction"... but is there a summary of what this actually describes? I see a 
lot of boilerplate text, and defining some new terms, but I don't actually know 
what I would implement after reading this.


Aaron Parecki
aaronparecki.com
@aaronpk


On Wed, Feb 1, 2017 at 3:48 PM, Thomas Hardjono 
mailto:hardj...@mit.edu>> wrote:

Folks,

This may be of interest. Its forward-looking, I know. Appreciate any comments 
on the draft.

Best.

/thomas/


From: internet-dra...@ietf.org 
[internet-dra...@ietf.org]
Sent: Wednesday, February 01, 2017 6:39 PM
To: Thomas Hardjono
Subject: New Version Notification for draft-hardjono-oauth-decentralized-00.txt

A new version of I-D, draft-hardjono-oauth-decentralized-00.txt
has been successfully submitted by Thomas Hardjono and posted to the
IETF repository.

Name:   draft-hardjono-oauth-decentralized
Revision:   00
Title:  Decentralized Service Architecture for OAuth2.0
Document date:  2017-02-01
Group:  Individual Submission
Pages:  21
URL:
https://www.ietf.org/internet-drafts/draft-hardjono-oauth-decentralized-00.txt
Status: 
https://datatracker.ietf.org/doc/draft-hardjono-oauth-decentralized/
Htmlized:   
https://tools.ietf.org/html/draft-hardjono-oauth-decentralized-00


Abstract:
   This document proposes an alternative service architecture for user-
   centric control of the sharing of resources, such as personal data,
   using the decentralized peer-to-peer computing paradigm.  The term
   'control' is used here to denote the full capacity of the user to
   freely select (i) the entities with whom to share resources (e.g.
   data), and (ii) the entities which provide services implementing
   user-controlled resource sharing.  The peer-to-peer service
   architecture uses a set of computing nodes called OAuth2.0 Nodes (ON)
   that are part of a peer-to-peer network as the basis for the
   decentralized service architecture.  Each OAuth2.0 Nodes is assumed
   to have the capability to provide AS-services, RS-services and
   Client-services.





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.

The IETF Secretariat

___
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] Alexey Melnikov's Discuss on draft-ietf-oauth-amr-values-05: (with DISCUSS and COMMENT)

[Alexey Melnikov]

Alexey Melnikov has entered the following ballot position for
draft-ietf-oauth-amr-values-05: Discuss

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-amr-values/



--
DISCUSS:
--

This is a fine document and I support its publication. However I have a
small set of issues that I would like to discuss first.

Are non ASCII names needed? (This is a protocol element, not a human
readable string, so non ASCII is not needed). Are ASCII spaces allowed in
names? More generally: what do you call printable character?


--
COMMENT:
--

In Section 6.1: suggestion to first describe IANA registration policy,
then describe restrictions on registered names. Otherwise the current
text doesn't flow well.

I am also agreeing with Stephen's DISCUSS.


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