Re: [OAUTH-WG] Fwd: New Version Notification for draft-lodderstedt-oauth-revocation-03.txt

[Torsten Lodderstedt]

  

Hi Craig, 

thanks for your comment. 

The revocation endpoint uses
the same authentication policy as the core spec. Confidential client
must authenticate using their client secret (or any other credential).
The end-user's credentials are not involved at all. 

regards,
Torsten.


Am 27.10.2011 08:10, schrieb Craig McClanahan: 

> As a substantive
comment on the draft (I'm in favor of it being a working group item), it
is not clear whether "Basic" is a required value on the "Authorization"
header included in a revocation request. In some scenarios (particularly
three legged), the client app will not possess the username and password
of they end user -- it might only possess a currently valid access
token. It would seem that including such a token should be a viable
authentication mechanism. 
> Craig McClanahan
> 
> On Fri, Sep 16, 2011
at 12:32 PM, Torsten Lodderstedt wrote:
> 
>> Hi all,
>> 
>> I just
published a new revision of the token revocation draft. We added JSONP
support (thanks to Marius) and aligned the text with draft 21 of the
core spec.
>> 
>> We would like to bring this draft forward as working
group item (once the WG is ready). We think its relevance is illustrated
by the fact that this draft (or its predecessor) has already been
implemented by Google, Salesforce, and Deutsche Telekom.
>> 
>>
regards,
>> Torsten.
>> 
>>  Original-Nachricht  
>> 
>>
BETREFF:
>> New Version Notification for
draft-lodderstedt-oauth-revocation-03.txt
>> 
>> DATUM:
>> Fri, 16 Sep
2011 12:20:14 -0700
>> 
>> VON:
>> internet-dra...@ietf.org [1]
>> 
>>
AN:
>> tors...@lodderstedt.net [2]
>> 
>> CC:
>> sdro...@gmx.de [3],
tors...@lodderstedt.net [4], mscurte...@google.com [5]
>> 
>> A new
version of I-D, draft-lodderstedt-oauth-revocation-03.txt has been
successfully submitted by Torsten Lodderstedt and posted to the IETF
repository.
>> 
>> Filename: draft-lodderstedt-oauth-revocation
>>
Revision: 03
>> Title: Token Revocation
>> Creation date: 2011-09-16
>>
WG ID: Individual Submission
>> Number of pages: 6
>> 
>> Abstract:
>>
This draft proposes an additional endpoint for OAuth authorization
>>
servers for revoking tokens.
>> 
>> The IETF Secretariat
>> 
>>
___
>> OAuth mailing list
>>
OAuth@ietf.org [6]
>> https://www.ietf.org/mailman/listinfo/oauth [7]

 


Links:
--
[1] mailto:internet-dra...@ietf.org
[2]
mailto:tors...@lodderstedt.net
[3] mailto:sdro...@gmx.de
[4]
mailto:tors...@lodderstedt.net
[5] mailto:mscurte...@google.com
[6]
mailto:OAuth@ietf.org
[7]
https://www.ietf.org/mailman/listinfo/oauth
[8]
mailto:tors...@lodderstedt.net
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Rechartering JSON based request.

[Igor Faynberg]

On 10/26/2011 6:31 PM, John Bradley wrote:
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Rechartering JSON based request.

[Igor Faynberg]

Many thanks for pointing this!  It is *absolutely* (not "probably") 
worth studying.


Igor

On 10/26/2011 6:31 PM, John Bradley wrote:

Nat and I just refreshed the I-D for draft-sakimura-oauth-requrl.

It is essentially  a standardization of the method we are using in 
openID Connect to make signed requests to the Authorization server.


We do have the issue that parameters in the signed/encrypted request 
necessarily duplicate the query parameters to keep it a valid OAuth 
request plus an extension.


Even if it doesn't wind up as a OAuth WG item it is probably worth 
people looking at it before the final openID spec is voted on.


Regards
John B.

On 2011-10-26, at 3:16 PM, Torsten Lodderstedt wrote:


Hi Nat,

I think your proposal would be a useful OAuth enhancement. A 
JSON-based request format would allow for more complex requests (e.g. 
carrying resource server URLs and corresponding scope values ;-)).


Please note: I also think the way this mechanism is introduced and 
used in the current OpenID connect spec requires OpenID connect 
clients and servers to handle OAuth request parameters differently 
than for standard OAuth requests. Introducing the JSON based claim 
request capability to OAuth would be a way to cope with this.


regards,
Torsten.

Am 22.10.2011 16:00, schrieb Nat Sakimura:

Hi.

Just a clarification:

Although my expired draft is 'request by reference', what was 
proposed through it at the iiw really is a generalized JSON based 
claim request capability. It could be passed by value as JSON or 
could be passed by reference. The later is an optimization for 
bandwidth constrained network as well as strengthening security in 
some ways. This capability already exists in OpenID Connect but it 
is actually an underpinning transport, so it probably should belong 
to OAuth instead. This was the primary reason for the proposal.


Nat

On Thu, Oct 20, 2011 at 3:56 PM, Torsten Lodderstedt 
mailto:tors...@lodderstedt.net>> wrote:


Hi all,

my prioritization is driven by the goal to make OAuth the
authorization framework of choice for any internet standard
protocol, such as WebDAV, IMAP, SMTP or SIP. So let me first
explain what is missing from my point of view and explain some
thoughts how to fill the gaps.

A standard protocol is defined in terms of resource types and
messages by a body (e.g. IETF, OIDF, OMA), (hopefully)
implemented in many places, and used by different but
deployment-independent clients. OAuth-based protocol
specifications must also define scope values (e.g. read, write,
send) and their relation to the resource types and messages. The
different deployments expose the standard protocol on different
resource server endpoints. In my opinion, it is fundamental to
clearly distinguish scope values (standardized, static) and
 resource server addresses (deployment specific) and to manage
their relationships. The current scope definition is much to
weak and insufficient. Probably, the UMA concepts of hosts,
resources sets, and corresponding scopes could be adopted for
that purpose.

OAuth today requires clients to register with the service
provider before they are deployed. Would you really expect IMAP
clients, e.g. Thunderbird, to register with any a-Mail services
upfront? So clients should be given a way to register
dynamically to the authorization servers. This should also allow
us to cover "client instance" aspects. It is interesting to
note, that such a mechanism would allow us to get rid of
secret-less clients and the one-time usage requirement for
authorization codes.

We also assume the client to know the URLs of the resource
server and the corresponding authorization server and to use
HTTPS server authentication to verify the resource server's
authenticity. This is impossible in the standard scenario.
Clients must be able to discover the authorization server a
particular resource server relies on at runtime. The discovery
mechanism could be specified by the OAuth WG, but could also be
part of an application protocols specification. But we MUST find
another way to prevent token phishing by counterfeit resource
servers.

As one approach, the client could pass the (previously HTTPS
validated) resource server's URL with the authorization request.
The authorization server should then refuse such requests for
any unknown (counterfeit) resource servers. Such an additional
parameter could also serve as namespace for scope values and
enable service providers to run multiple instances of the same
service within a single deployment.

If the additional data enlarges the request payload to much, we
could consider to adopt the "request by reference" proposal.

Let's now assume, OAuth is successful in the world of standard
protocols and we will see plenty of deployments with a bunch of
 

Re: [OAUTH-WG] Rechartering JSON based request.

[John Bradley]

Hopefully to make it more compatible with existing OAuth 2 libraries.At 
least leave open the possibility of dealing with it at a higher level.

The argument has been made that you probably need to modify the library anyway 
to check that the duplicate parameters are a match.

If there is consensus that the parameters should only be in the JSON then we 
would happily not duplicate them.

It is mostly a case of trying to fit in to the existing OAuth work and 
libraries.

John B.

On 2011-10-27, at 2:22 AM, Torsten Lodderstedt wrote:

> why is it neccessary to duplicate the OAuth request parameters?
> 
> Am 27.10.2011 00:31, schrieb John Bradley:
>> 
>> Nat and I just refreshed the I-D for draft-sakimura-oauth-requrl.
>> 
>> It is essentially  a standardization of the method we are using in openID 
>> Connect to make signed requests to the Authorization server.
>> 
>> We do have the issue that parameters in the signed/encrypted request 
>> necessarily duplicate the query parameters to keep it a valid OAuth request 
>> plus an extension.
>> 
>> Even if it doesn't wind up as a OAuth WG item it is probably worth people 
>> looking at it before the final openID spec is voted on.
>> 
>> Regards
>> John B.
>> 
>> On 2011-10-26, at 3:16 PM, Torsten Lodderstedt wrote:
>> 
>>> Hi Nat,
>>> 
>>> I think your proposal would be a useful OAuth enhancement. A JSON-based 
>>> request format would allow for more complex requests (e.g. carrying 
>>> resource server URLs and corresponding scope values ;-)). 
>>> 
>>> Please note: I also think the way this mechanism is introduced and used in 
>>> the current OpenID connect spec requires OpenID connect clients and servers 
>>> to handle OAuth request parameters differently than for standard OAuth 
>>> requests. Introducing the JSON based claim request capability to OAuth 
>>> would be a way to cope with this.
>>> 
>>> regards,
>>> Torsten.
>>> 
>>> Am 22.10.2011 16:00, schrieb Nat Sakimura:
 
 Hi. 
 
 Just a clarification: 
 
 Although my expired draft is 'request by reference', what was proposed 
 through it at the iiw really is a generalized JSON based claim request 
 capability. It could be passed by value as JSON or could be passed by 
 reference. The later is an optimization for bandwidth constrained network 
 as well as strengthening security in some ways. This capability already 
 exists in OpenID Connect but it is actually an underpinning transport, so 
 it probably should belong to OAuth instead. This was the primary reason 
 for the proposal. 
 
 Nat
 
 On Thu, Oct 20, 2011 at 3:56 PM, Torsten Lodderstedt 
  wrote:
 Hi all,
 
 my prioritization is driven by the goal to make OAuth the authorization 
 framework of choice for any internet standard protocol, such as WebDAV, 
 IMAP, SMTP or SIP. So let me first explain what is missing from my point 
 of view and explain some thoughts how to fill the gaps.
 
 A standard protocol is defined in terms of resource types and messages by 
 a body (e.g. IETF, OIDF, OMA), (hopefully) implemented in many places, and 
 used by different but deployment-independent clients. OAuth-based protocol 
 specifications must also define scope values (e.g. read, write, send) and 
 their relation to the resource types and messages. The different 
 deployments expose the standard protocol on different resource server 
 endpoints. In my opinion, it is fundamental to clearly distinguish scope 
 values (standardized, static) and  resource server addresses (deployment 
 specific) and to manage their relationships. The current scope definition 
 is much to weak and insufficient. Probably, the UMA concepts of hosts, 
 resources sets, and corresponding scopes could be adopted for that purpose.
 
 OAuth today requires clients to register with the service provider before 
 they are deployed. Would you really expect IMAP clients, e.g. Thunderbird, 
 to register with any a-Mail services upfront? So clients should be given a 
 way to register dynamically to the authorization servers. This should also 
 allow us to cover "client instance" aspects. It is interesting to note, 
 that such a mechanism would allow us to get rid of secret-less clients and 
 the one-time usage requirement for authorization codes.
 
 We also assume the client to know the URLs of the resource server and the 
 corresponding authorization server and to use HTTPS server authentication 
 to verify the resource server's authenticity. This is impossible in the 
 standard scenario. Clients must be able to discover the authorization 
 server a particular resource server relies on at runtime. The discovery 
 mechanism could be specified by the OAuth WG, but could also be part of an 
 application protocols specification. But we MUST find another way to 
 prevent token phishing by coun

Re: [OAUTH-WG] Rechartering JSON based request.

[torsten]

Hi John,

why do you need to include the OAuth request parameters into the JSON document? 
I would expect OpenId Connect to extend OAuth none-intrusively. This would mean 
to use the JSON document for OpenId connect specific parameters only. 
Alternatively, the JSON request style could be adopted as part of OAuth. Then, 
the URI request parameters could be omitted.

regards,
Torsten.
Gesendet mit BlackBerry® Webmail von Telekom Deutschland  

-Original Message-
From: John Bradley 
Date: Thu, 27 Oct 2011 13:52:31 
To: Torsten Lodderstedt
Cc: Nat Sakimura; OAuth WG
Subject: Re: [OAUTH-WG] Rechartering JSON based request.

Hopefully to make it more compatible with existing OAuth 2 libraries.At 
least leave open the possibility of dealing with it at a higher level.

The argument has been made that you probably need to modify the library anyway 
to check that the duplicate parameters are a match.

If there is consensus that the parameters should only be in the JSON then we 
would happily not duplicate them.

It is mostly a case of trying to fit in to the existing OAuth work and 
libraries.

John B.

On 2011-10-27, at 2:22 AM, Torsten Lodderstedt wrote:

> why is it neccessary to duplicate the OAuth request parameters?
> 
> Am 27.10.2011 00:31, schrieb John Bradley:
>> 
>> Nat and I just refreshed the I-D for draft-sakimura-oauth-requrl.
>> 
>> It is essentially  a standardization of the method we are using in openID 
>> Connect to make signed requests to the Authorization server.
>> 
>> We do have the issue that parameters in the signed/encrypted request 
>> necessarily duplicate the query parameters to keep it a valid OAuth request 
>> plus an extension.
>> 
>> Even if it doesn't wind up as a OAuth WG item it is probably worth people 
>> looking at it before the final openID spec is voted on.
>> 
>> Regards
>> John B.
>> 
>> On 2011-10-26, at 3:16 PM, Torsten Lodderstedt wrote:
>> 
>>> Hi Nat,
>>> 
>>> I think your proposal would be a useful OAuth enhancement. A JSON-based 
>>> request format would allow for more complex requests (e.g. carrying 
>>> resource server URLs and corresponding scope values ;-)). 
>>> 
>>> Please note: I also think the way this mechanism is introduced and used in 
>>> the current OpenID connect spec requires OpenID connect clients and servers 
>>> to handle OAuth request parameters differently than for standard OAuth 
>>> requests. Introducing the JSON based claim request capability to OAuth 
>>> would be a way to cope with this.
>>> 
>>> regards,
>>> Torsten.
>>> 
>>> Am 22.10.2011 16:00, schrieb Nat Sakimura:
 
 Hi. 
 
 Just a clarification: 
 
 Although my expired draft is 'request by reference', what was proposed 
 through it at the iiw really is a generalized JSON based claim request 
 capability. It could be passed by value as JSON or could be passed by 
 reference. The later is an optimization for bandwidth constrained network 
 as well as strengthening security in some ways. This capability already 
 exists in OpenID Connect but it is actually an underpinning transport, so 
 it probably should belong to OAuth instead. This was the primary reason 
 for the proposal. 
 
 Nat
 
 On Thu, Oct 20, 2011 at 3:56 PM, Torsten Lodderstedt 
  wrote:
 Hi all,
 
 my prioritization is driven by the goal to make OAuth the authorization 
 framework of choice for any internet standard protocol, such as WebDAV, 
 IMAP, SMTP or SIP. So let me first explain what is missing from my point 
 of view and explain some thoughts how to fill the gaps.
 
 A standard protocol is defined in terms of resource types and messages by 
 a body (e.g. IETF, OIDF, OMA), (hopefully) implemented in many places, and 
 used by different but deployment-independent clients. OAuth-based protocol 
 specifications must also define scope values (e.g. read, write, send) and 
 their relation to the resource types and messages. The different 
 deployments expose the standard protocol on different resource server 
 endpoints. In my opinion, it is fundamental to clearly distinguish scope 
 values (standardized, static) and  resource server addresses (deployment 
 specific) and to manage their relationships. The current scope definition 
 is much to weak and insufficient. Probably, the UMA concepts of hosts, 
 resources sets, and corresponding scopes could be adopted for that purpose.
 
 OAuth today requires clients to register with the service provider before 
 they are deployed. Would you really expect IMAP clients, e.g. Thunderbird, 
 to register with any a-Mail services upfront? So clients should be given a 
 way to register dynamically to the authorization servers. This should also 
 allow us to cover "client instance" aspects. It is interesting to note, 
 that such a mechanism would allow us to get rid of secret-less clients and 
 the one-t

Re: [OAUTH-WG] Rechartering JSON based request.

[Phil Hunt]

John,

What is the reason behind having a separate ID_Token from the access Token?  I 
understand the tokens are used to retrieve different information, but not sure 
I fully understand why separate tokens are needed.

I ask because I recall others have asked for multi-token response….trying to 
understand if there is a general use case behind this requirement.

Phil

@independentid
www.independentid.com
phil.h...@oracle.com





On 2011-10-27, at 10:33 AM, tors...@lodderstedt.net wrote:

> Hi John,
> 
> why do you need to include the OAuth request parameters into the JSON 
> document? I would expect OpenId Connect to extend OAuth none-intrusively. 
> This would mean to use the JSON document for OpenId connect specific 
> parameters only. Alternatively, the JSON request style could be adopted as 
> part of OAuth. Then, the URI request parameters could be omitted.
> 
> regards,
> Torsten.
> Gesendet mit BlackBerry® Webmail von Telekom Deutschland
> 
> From: John Bradley 
> Date: Thu, 27 Oct 2011 13:52:31 -0300
> To: Torsten Lodderstedt
> Cc: Nat Sakimura; OAuth WG
> Subject: Re: [OAUTH-WG] Rechartering JSON based request.
> 
> Hopefully to make it more compatible with existing OAuth 2 libraries.At 
> least leave open the possibility of dealing with it at a higher level.
> 
> The argument has been made that you probably need to modify the library 
> anyway to check that the duplicate parameters are a match.
> 
> If there is consensus that the parameters should only be in the JSON then we 
> would happily not duplicate them.
> 
> It is mostly a case of trying to fit in to the existing OAuth work and 
> libraries.
> 
> John B.
> 
> On 2011-10-27, at 2:22 AM, Torsten Lodderstedt wrote:
> 
>> why is it neccessary to duplicate the OAuth request parameters?
>> 
>> Am 27.10.2011 00:31, schrieb John Bradley:
>>> 
>>> Nat and I just refreshed the I-D for draft-sakimura-oauth-requrl.
>>> 
>>> It is essentially  a standardization of the method we are using in openID 
>>> Connect to make signed requests to the Authorization server.
>>> 
>>> We do have the issue that parameters in the signed/encrypted request 
>>> necessarily duplicate the query parameters to keep it a valid OAuth request 
>>> plus an extension.
>>> 
>>> Even if it doesn't wind up as a OAuth WG item it is probably worth people 
>>> looking at it before the final openID spec is voted on.
>>> 
>>> Regards
>>> John B.
>>> 
>>> On 2011-10-26, at 3:16 PM, Torsten Lodderstedt wrote:
>>> 
 Hi Nat,
 
 I think your proposal would be a useful OAuth enhancement. A JSON-based 
 request format would allow for more complex requests (e.g. carrying 
 resource server URLs and corresponding scope values ;-)). 
 
 Please note: I also think the way this mechanism is introduced and used in 
 the current OpenID connect spec requires OpenID connect clients and 
 servers to handle OAuth request parameters differently than for standard 
 OAuth requests. Introducing the JSON based claim request capability to 
 OAuth would be a way to cope with this.
 
 regards,
 Torsten.
 
 Am 22.10.2011 16:00, schrieb Nat Sakimura:
> 
> Hi. 
> 
> Just a clarification: 
> 
> Although my expired draft is 'request by reference', what was proposed 
> through it at the iiw really is a generalized JSON based claim request 
> capability. It could be passed by value as JSON or could be passed by 
> reference. The later is an optimization for bandwidth constrained network 
> as well as strengthening security in some ways. This capability already 
> exists in OpenID Connect but it is actually an underpinning transport, so 
> it probably should belong to OAuth instead. This was the primary reason 
> for the proposal. 
> 
> Nat
> 
> On Thu, Oct 20, 2011 at 3:56 PM, Torsten Lodderstedt 
>  wrote:
> Hi all,
> 
> my prioritization is driven by the goal to make OAuth the authorization 
> framework of choice for any internet standard protocol, such as WebDAV, 
> IMAP, SMTP or SIP. So let me first explain what is missing from my point 
> of view and explain some thoughts how to fill the gaps.
> 
> A standard protocol is defined in terms of resource types and messages by 
> a body (e.g. IETF, OIDF, OMA), (hopefully) implemented in many places, 
> and used by different but deployment-independent clients. OAuth-based 
> protocol specifications must also define scope values (e.g. read, write, 
> send) and their relation to the resource types and messages. The 
> different deployments expose the standard protocol on different resource 
> server endpoints. In my opinion, it is fundamental to clearly distinguish 
> scope values (standardized, static) and  resource server addresses 
> (deployment specific) and to manage their relationships. The current 
> scope definition is much to weak and insufficient. Probably, t

Re: [OAUTH-WG] Rechartering JSON based request.

[Mike Jones]

In OpenID Connect, the two tokens are used to access two different sets of 
resources:  the "id_token" for claims about the logged-in session and the 
"code" token to access the UserInfo endpoint for claims about the user.

FYI, see http://openid.net/specs/oauth-v2-multiple-response-types-1_0.html for 
a write-up on encoding multiple response types.  (I'm told that at least parts 
of this are already being used by Google and Facebook.)

-- Mike

From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Phil 
Hunt
Sent: Thursday, October 27, 2011 10:49 AM
To: tors...@lodderstedt.net
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Rechartering JSON based request.

John,

What is the reason behind having a separate ID_Token from the access Token?  I 
understand the tokens are used to retrieve different information, but not sure 
I fully understand why separate tokens are needed.

I ask because I recall others have asked for multi-token responsetrying to 
understand if there is a general use case behind this requirement.

Phil

@independentid
www.independentid.com
phil.h...@oracle.com




On 2011-10-27, at 10:33 AM, 
tors...@lodderstedt.net wrote:


Hi John,

why do you need to include the OAuth request parameters into the JSON document? 
I would expect OpenId Connect to extend OAuth none-intrusively. This would mean 
to use the JSON document for OpenId connect specific parameters only. 
Alternatively, the JSON request style could be adopted as part of OAuth. Then, 
the URI request parameters could be omitted.

regards,
Torsten.

Gesendet mit BlackBerry(r) Webmail von Telekom Deutschland


From: John Bradley mailto:ve7...@ve7jtb.com>>
Date: Thu, 27 Oct 2011 13:52:31 -0300
To: Torsten Lodderstedtmailto:tors...@lodderstedt.net>>
Cc: Nat Sakimuramailto:sakim...@gmail.com>>; OAuth 
WGmailto:oauth@ietf.org>>
Subject: Re: [OAUTH-WG] Rechartering JSON based request.

Hopefully to make it more compatible with existing OAuth 2 libraries.At 
least leave open the possibility of dealing with it at a higher level.

The argument has been made that you probably need to modify the library anyway 
to check that the duplicate parameters are a match.

If there is consensus that the parameters should only be in the JSON then we 
would happily not duplicate them.

It is mostly a case of trying to fit in to the existing OAuth work and 
libraries.

John B.

On 2011-10-27, at 2:22 AM, Torsten Lodderstedt wrote:


why is it neccessary to duplicate the OAuth request parameters?

Am 27.10.2011 00:31, schrieb John Bradley:
Nat and I just refreshed the I-D for draft-sakimura-oauth-requrl.

It is essentially  a standardization of the method we are using in openID 
Connect to make signed requests to the Authorization server.

We do have the issue that parameters in the signed/encrypted request 
necessarily duplicate the query parameters to keep it a valid OAuth request 
plus an extension.

Even if it doesn't wind up as a OAuth WG item it is probably worth people 
looking at it before the final openID spec is voted on.

Regards
John B.

On 2011-10-26, at 3:16 PM, Torsten Lodderstedt wrote:


Hi Nat,

I think your proposal would be a useful OAuth enhancement. A JSON-based request 
format would allow for more complex requests (e.g. carrying resource server 
URLs and corresponding scope values ;-)).

Please note: I also think the way this mechanism is introduced and used in the 
current OpenID connect spec requires OpenID connect clients and servers to 
handle OAuth request parameters differently than for standard OAuth requests. 
Introducing the JSON based claim request capability to OAuth would be a way to 
cope with this.

regards,
Torsten.

Am 22.10.2011 16:00, schrieb Nat Sakimura:
Hi.

Just a clarification:

Although my expired draft is 'request by reference', what was proposed through 
it at the iiw really is a generalized JSON based claim request capability. It 
could be passed by value as JSON or could be passed by reference. The later is 
an optimization for bandwidth constrained network as well as strengthening 
security in some ways. This capability already exists in OpenID Connect but it 
is actually an underpinning transport, so it probably should belong to OAuth 
instead. This was the primary reason for the proposal.

Nat

On Thu, Oct 20, 2011 at 3:56 PM, Torsten Lodderstedt 
mailto:tors...@lodderstedt.net>> wrote:
Hi all,

my prioritization is driven by the goal to make OAuth the authorization 
framework of choice for any internet standard protocol, such as WebDAV, IMAP, 
SMTP or SIP. So let me first explain what is missing from my point of view and 
explain some thoughts how to fill the gaps.

A standard protocol is defined in terms of resource types and messages by a 
body (e.g. IETF, OIDF, OMA), (hopefully) implemented in many pl

Re: [OAUTH-WG] Rechartering JSON based request.

[Phil Hunt]

Mike,

Why can't the same access token be used for both services?  Is it because the 
services have different security systems and demand different tokens?  Why not 
a single token for both?

Phil

@independentid
www.independentid.com
phil.h...@oracle.com





On 2011-10-27, at 10:55 AM, Mike Jones wrote:

> In OpenID Connect, the two tokens are used to access two different sets of 
> resources:  the “id_token” for claims about the logged-in session and the 
> “code” token to access the UserInfo endpoint for claims about the user.
>  
> FYI, see http://openid.net/specs/oauth-v2-multiple-response-types-1_0.html 
> for a write-up on encoding multiple response types.  (I’m told that at least 
> parts of this are already being used by Google and Facebook.)
>  
> -- Mike
>  
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of 
> Phil Hunt
> Sent: Thursday, October 27, 2011 10:49 AM
> To: tors...@lodderstedt.net
> Cc: OAuth WG
> Subject: Re: [OAUTH-WG] Rechartering JSON based request.
>  
> John,
>  
> What is the reason behind having a separate ID_Token from the access Token?  
> I understand the tokens are used to retrieve different information, but not 
> sure I fully understand why separate tokens are needed.
>  
> I ask because I recall others have asked for multi-token response….trying to 
> understand if there is a general use case behind this requirement.
>  
> Phil
>  
> @independentid
> www.independentid.com
> phil.h...@oracle.com
> 
>  
> 
> 
>  
> On 2011-10-27, at 10:33 AM, tors...@lodderstedt.net wrote:
> 
> 
> Hi John,
> 
> why do you need to include the OAuth request parameters into the JSON 
> document? I would expect OpenId Connect to extend OAuth none-intrusively. 
> This would mean to use the JSON document for OpenId connect specific 
> parameters only. Alternatively, the JSON request style could be adopted as 
> part of OAuth. Then, the URI request parameters could be omitted.
> 
> regards,
> Torsten.
> Gesendet mit BlackBerry® Webmail von Telekom Deutschland
> 
> From: John Bradley 
> Date: Thu, 27 Oct 2011 13:52:31 -0300
> To: Torsten Lodderstedt
> Cc: Nat Sakimura; OAuth WG
> Subject: Re: [OAUTH-WG] Rechartering JSON based request.
>  
> Hopefully to make it more compatible with existing OAuth 2 libraries.At 
> least leave open the possibility of dealing with it at a higher level.
>  
> The argument has been made that you probably need to modify the library 
> anyway to check that the duplicate parameters are a match.
>  
> If there is consensus that the parameters should only be in the JSON then we 
> would happily not duplicate them.
>  
> It is mostly a case of trying to fit in to the existing OAuth work and 
> libraries.
>  
> John B.
>  
> On 2011-10-27, at 2:22 AM, Torsten Lodderstedt wrote:
> 
> 
> why is it neccessary to duplicate the OAuth request parameters?
> 
> Am 27.10.2011 00:31, schrieb John Bradley:
> Nat and I just refreshed the I-D for draft-sakimura-oauth-requrl.
>  
> It is essentially  a standardization of the method we are using in openID 
> Connect to make signed requests to the Authorization server.
>  
> We do have the issue that parameters in the signed/encrypted request 
> necessarily duplicate the query parameters to keep it a valid OAuth request 
> plus an extension.
>  
> Even if it doesn't wind up as a OAuth WG item it is probably worth people 
> looking at it before the final openID spec is voted on.
>  
> Regards
> John B.
>  
> On 2011-10-26, at 3:16 PM, Torsten Lodderstedt wrote:
> 
> 
> Hi Nat,
> 
> I think your proposal would be a useful OAuth enhancement. A JSON-based 
> request format would allow for more complex requests (e.g. carrying resource 
> server URLs and corresponding scope values ;-)). 
> 
> Please note: I also think the way this mechanism is introduced and used in 
> the current OpenID connect spec requires OpenID connect clients and servers 
> to handle OAuth request parameters differently than for standard OAuth 
> requests. Introducing the JSON based claim request capability to OAuth would 
> be a way to cope with this.
> 
> regards,
> Torsten.
> 
> Am 22.10.2011 16:00, schrieb Nat Sakimura:
> Hi. 
>  
> Just a clarification: 
>  
> Although my expired draft is 'request by reference', what was proposed 
> through it at the iiw really is a generalized JSON based claim request 
> capability. It could be passed by value as JSON or could be passed by 
> reference. The later is an optimization for bandwidth constrained network as 
> well as strengthening security in some ways. This capability already exists 
> in OpenID Connect but it is actually an underpinning transport, so it 
> probably should belong to OAuth instead. This was the primary reason for the 
> proposal. 
>  
> Nat
>  
> On Thu, Oct 20, 2011 at 3:56 PM, Torsten Lodderstedt 
>  wrote:
> Hi all,
> 
> my prioritization is driven by the goal to make OAuth the authorization 
> framework of

Re: [OAUTH-WG] Rechartering JSON based request.

[George Fletcher]

The main reason to include the OAuth parameters in the request is to 
ensure that the request object was not modified in transit since the 
JSON request object can be signed. Agreed that it would be simpler if 
OAuth adopted the JSON request style.


Thanks,
George

On 10/27/11 1:33 PM, tors...@lodderstedt.net wrote:

Hi John,

why do you need to include the OAuth request parameters into the JSON 
document? I would expect OpenId Connect to extend OAuth 
none-intrusively. This would mean to use the JSON document for OpenId 
connect specific parameters only. Alternatively, the JSON request 
style could be adopted as part of OAuth. Then, the URI request 
parameters could be omitted.


regards,
Torsten.

Gesendet mit BlackBerry® Webmail von Telekom Deutschland


*From: * John Bradley 
*Date: *Thu, 27 Oct 2011 13:52:31 -0300
*To: *Torsten Lodderstedt
*Cc: *Nat Sakimura; OAuth WG
*Subject: *Re: [OAUTH-WG] Rechartering JSON based request.

Hopefully to make it more compatible with existing OAuth 2 libraries. 
   At least leave open the possibility of dealing with it at a higher 
level.


The argument has been made that you probably need to modify the 
library anyway to check that the duplicate parameters are a match.


If there is consensus that the parameters should only be in the JSON 
then we would happily not duplicate them.


It is mostly a case of trying to fit in to the existing OAuth work and 
libraries.


John B.

On 2011-10-27, at 2:22 AM, Torsten Lodderstedt wrote:


why is it neccessary to duplicate the OAuth request parameters?

Am 27.10.2011 00:31, schrieb John Bradley:

Nat and I just refreshed the I-D for draft-sakimura-oauth-requrl.

It is essentially  a standardization of the method we are using in 
openID Connect to make signed requests to the Authorization server.


We do have the issue that parameters in the signed/encrypted request 
necessarily duplicate the query parameters to keep it a valid OAuth 
request plus an extension.


Even if it doesn't wind up as a OAuth WG item it is probably worth 
people looking at it before the final openID spec is voted on.


Regards
John B.

On 2011-10-26, at 3:16 PM, Torsten Lodderstedt wrote:


Hi Nat,

I think your proposal would be a useful OAuth enhancement. A 
JSON-based request format would allow for more complex requests 
(e.g. carrying resource server URLs and corresponding scope values 
;-)).


Please note: I also think the way this mechanism is introduced and 
used in the current OpenID connect spec requires OpenID connect 
clients and servers to handle OAuth request parameters differently 
than for standard OAuth requests. Introducing the JSON based claim 
request capability to OAuth would be a way to cope with this.


regards,
Torsten.

Am 22.10.2011 16:00, schrieb Nat Sakimura:

Hi.

Just a clarification:

Although my expired draft is 'request by reference', what was 
proposed through it at the iiw really is a generalized JSON based 
claim request capability. It could be passed by value as JSON or 
could be passed by reference. The later is an optimization for 
bandwidth constrained network as well as strengthening security in 
some ways. This capability already exists in OpenID Connect but it 
is actually an underpinning transport, so it probably should 
belong to OAuth instead. This was the primary reason for the 
proposal.


Nat

On Thu, Oct 20, 2011 at 3:56 PM, Torsten Lodderstedt 
mailto:tors...@lodderstedt.net>> wrote:


Hi all,

my prioritization is driven by the goal to make OAuth the
authorization framework of choice for any internet standard
protocol, such as WebDAV, IMAP, SMTP or SIP. So let me first
explain what is missing from my point of view and explain some
thoughts how to fill the gaps.

A standard protocol is defined in terms of resource types and
messages by a body (e.g. IETF, OIDF, OMA), (hopefully)
implemented in many places, and used by different but
deployment-independent clients. OAuth-based protocol
specifications must also define scope values (e.g. read,
write, send) and their relation to the resource types and
messages. The different deployments expose the standard
protocol on different resource server endpoints. In my
opinion, it is fundamental to clearly distinguish scope values
(standardized, static) and  resource server addresses
(deployment specific) and to manage their relationships. The
current scope definition is much to weak and insufficient.
Probably, the UMA concepts of hosts, resources sets, and
corresponding scopes could be adopted for that purpose.

OAuth today requires clients to register with the service
provider before they are deployed. Would you really expect
IMAP clients, e.g. Thunderbird, to register with any a-Mail
services upfront? So clients should be given a way to register
dynamically to the authorization servers. This sho

[OAUTH-WG] I-D Action: draft-ietf-oauth-v2-bearer-12.txt

[internet-drafts]

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   : The OAuth 2.0 Authorization Protocol: Bearer Tokens
Author(s)   : Michael B. Jones
  Dick Hardt
  David Recordon
Filename: draft-ietf-oauth-v2-bearer-12.txt
Pages   : 19
Date: 2011-10-27

   This specification describes how to use bearer tokens in HTTP
   requests to access OAuth 2.0 protected resources.  Any party in
   possession of a bearer token (a "bearer") can use it to get access 
to
   granted resources (without demonstrating possession of a
   cryptographic key).  To prevent misuse, the bearer token needs to be
   protected from disclosure in storage and in transport.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-12.txt

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

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-12.txt
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] OAuth 2.0 Bearer Token Specification Draft -12

[Mike Jones]

Draft 12 of the OAuth 2.0 Bearer Token 
Specification has 
been published.  I believe that the chairs will be submitting this version to 
the IESG.  It contains the following changes:

  *   Made non-normative editorial changes that Hannes Tschofenig requested be 
applied prior to forwarding the specification to the IESG.
  *   Added rationale for the choice of the b64token syntax.
  *   Added rationale stating that receivers are free to parse the scope 
attribute using a standard quoted-string parser, since it will correctly 
process all legal scope values.
  *   Added additional active working group contributors to the 
Acknowledgements section.

The draft is available at these locations:

* http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-12

* http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-12.pdf

* http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-12.txt

* http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-12.xml

* http://self-issued.info/docs/draft-ietf-oauth-v2-bearer-12.html

* http://self-issued.info/docs/draft-ietf-oauth-v2-bearer-12.pdf

* http://self-issued.info/docs/draft-ietf-oauth-v2-bearer-12.txt

* http://self-issued.info/docs/draft-ietf-oauth-v2-bearer-12.xml

* http://self-issued.info/docs/draft-ietf-oauth-v2-bearer.html (will 
point to new versions as they are posted)

* http://self-issued.info/docs/draft-ietf-oauth-v2-bearer.pdf (will 
point to new versions as they are posted)

* http://self-issued.info/docs/draft-ietf-oauth-v2-bearer.txt (will 
point to new versions as they are posted)

* http://self-issued.info/docs/draft-ietf-oauth-v2-bearer.xml (will 
point to new versions as they are posted)

* http://svn.openid.net/repos/specifications/oauth/2.0/ (Subversion 
repository, with html, pdf, txt, and html versions available)

-- Mike

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

Re: [OAUTH-WG] OAuth 2.0 Bearer Token Specification Draft -12

[Hannes Tschofenig]

Thank you Mike for your work on the specification and to get the feedback 
incorporated before the deadline. 

On Oct 28, 2011, at 12:01 AM, Mike Jones wrote:

> Draft 12 of the OAuth 2.0 Bearer Token Specification has been published.  I 
> believe that the chairs will be submitting this version to the IESG.  It 
> contains the following changes:
>   • Made non-normative editorial changes that Hannes Tschofenig requested 
> be applied prior to forwarding the specification to the IESG.
>   • Added rationale for the choice of the b64token syntax.
>   • Added rationale stating that receivers are free to parse the scope 
> attribute using a standard quoted-string parser, since it will correctly 
> process all legal scopevalues.
>   • Added additional active working group contributors to the 
> Acknowledgements section.
>  
> The draft is available at these locations:
> · http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-12
> · 
> http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-12.pdf
> · 
> http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-12.txt
> · 
> http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-12.xml
> · http://self-issued.info/docs/draft-ietf-oauth-v2-bearer-12.html
> · http://self-issued.info/docs/draft-ietf-oauth-v2-bearer-12.pdf
> · http://self-issued.info/docs/draft-ietf-oauth-v2-bearer-12.txt
> · http://self-issued.info/docs/draft-ietf-oauth-v2-bearer-12.xml
> · http://self-issued.info/docs/draft-ietf-oauth-v2-bearer.html (will 
> point to new versions as they are posted)
> · http://self-issued.info/docs/draft-ietf-oauth-v2-bearer.pdf (will 
> point to new versions as they are posted)
> · http://self-issued.info/docs/draft-ietf-oauth-v2-bearer.txt (will 
> point to new versions as they are posted)
> · http://self-issued.info/docs/draft-ietf-oauth-v2-bearer.xml (will 
> point to new versions as they are posted)
> · http://svn.openid.net/repos/specifications/oauth/2.0/ (Subversion 
> repository, with html, pdf, txt, and html versions available)
>  
> -- 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] draft-ietf-oauth-v2-bearer-12: ABNF nits

[Manger, James H]

The  value should just be .
The current ABNF implies you can include raw (unescaped) " and \ characters in 
the value (as they are chars in ) - but that breaks parsing.
If the intention was not to allow senders to use escapes then  
needs to be <%x20-%x21 / %x23-5B / %x5D-7E>. If that is the intention why not 
disallow escapes from  as well?

Section 3 "The WWW-Authenticate Response Header Field"
OLD:
error-desc  = "error_description" "=" DQUOTE *error-desc-char DQUOTE
error-desc-char = SP / VCHAR
NEW:
error-desc  = "error_description" "=" quoted-string

The note about being allowed to parse  with a quoted-string parser 
should also apply to  and  as well.


Perhaps a better approach is to: defined , , , and 
 values as ; add text saying senders MUST NOT use 
quoted-string's escape mechanism (so " and \ cannot appear in the values), 
though receivers MAY use a standard quoted-string parser; say the  
value must match ; say the  value is a list of 
space-delimited, case sensitive strings.


NEW:
  scope = "scope" "=" quoted-string
  error = "error" "=" quoted-string
  error-desc = "error_description" "=" quoted-string
  error-uri = "error_uri" "=" quoted-string

  Senders MUST NOT use the quoted-string escape mechanism for
  "scope", "error", "error_description", or "error_uri" values.
  That is, those values cannot include " or \.
  Receivers MAY use a standard quoted-string parser, and hence
  accept some values that are not allowed to be sent.

  An "error_uri" value MUST match the URI-reference rule
  from [RFC3986].

  The "scope" value is a list of space-delimited, case sensitive
  strings. ...


P.S. trivial typo: "URI-Reference" should be "URI-reference" in §1.1.

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

Re: [OAUTH-WG] Rechartering JSON based request.

[Nat Sakimura]

Thanks George.

Just to clarify the intent of this I-D : this I-D proposes the JSON request
style to be adopted as part of OAuth so that the URI request parameters
could be omitted.

=nat

On Fri, Oct 28, 2011 at 5:24 AM, George Fletcher  wrote:

>  The main reason to include the OAuth parameters in the request is to
> ensure that the request object was not modified in transit since the JSON
> request object can be signed. Agreed that it would be simpler if OAuth
> adopted the JSON request style.
>
> Thanks,
> George
>
> On 10/27/11 1:33 PM, tors...@lodderstedt.net wrote:
>
> Hi John,
>
> why do you need to include the OAuth request parameters into the JSON
> document? I would expect OpenId Connect to extend OAuth none-intrusively.
> This would mean to use the JSON document for OpenId connect specific
> parameters only. Alternatively, the JSON request style could be adopted as
> part of OAuth. Then, the URI request parameters could be omitted.
>
> regards,
> Torsten.
>
> Gesendet mit BlackBerry® Webmail von Telekom Deutschland
> --
> *From: * John Bradley  
> *Date: *Thu, 27 Oct 2011 13:52:31 -0300
> *To: *Torsten Lodderstedt
> *Cc: *Nat Sakimura ; OAuth WG
>  
> *Subject: *Re: [OAUTH-WG] Rechartering JSON based request.
>
>  Hopefully to make it more compatible with existing OAuth 2 libraries.
>  At least leave open the possibility of dealing with it at a higher level.
>
>  The argument has been made that you probably need to modify the library
> anyway to check that the duplicate parameters are a match.
>
>  If there is consensus that the parameters should only be in the JSON then
> we would happily not duplicate them.
>
>  It is mostly a case of trying to fit in to the existing OAuth work and
> libraries.
>
>  John B.
>
>  On 2011-10-27, at 2:22 AM, Torsten Lodderstedt wrote:
>
>  why is it neccessary to duplicate the OAuth request parameters?
>
> Am 27.10.2011 00:31, schrieb John Bradley:
>
> Nat and I just refreshed the I-D for draft-sakimura-oauth-requrl.
>
>  It is essentially  a standardization of the method we are using in openID
> Connect to make signed requests to the Authorization server.
>
>  We do have the issue that parameters in the signed/encrypted request
> necessarily duplicate the query parameters to keep it a valid OAuth request
> plus an extension.
>
>  Even if it doesn't wind up as a OAuth WG item it is probably worth people
> looking at it before the final openID spec is voted on.
>
>  Regards
> John B.
>
>  On 2011-10-26, at 3:16 PM, Torsten Lodderstedt wrote:
>
>  Hi Nat,
>
> I think your proposal would be a useful OAuth enhancement. A JSON-based
> request format would allow for more complex requests (e.g. carrying resource
> server URLs and corresponding scope values ;-)).
>
> Please note: I also think the way this mechanism is introduced and used in
> the current OpenID connect spec requires OpenID connect clients and servers
> to handle OAuth request parameters differently than for standard OAuth
> requests. Introducing the JSON based claim request capability to OAuth would
> be a way to cope with this.
>
> regards,
> Torsten.
>
> Am 22.10.2011 16:00, schrieb Nat Sakimura:
>
> Hi.
>
>  Just a clarification:
>
>  Although my expired draft is 'request by reference', what was proposed
> through it at the iiw really is a generalized JSON based claim request
> capability. It could be passed by value as JSON or could be passed by
> reference. The later is an optimization for bandwidth constrained network as
> well as strengthening security in some ways. This capability already exists
> in OpenID Connect but it is actually an underpinning transport, so it
> probably should belong to OAuth instead. This was the primary reason for the
> proposal.
>
>  Nat
>
> On Thu, Oct 20, 2011 at 3:56 PM, Torsten Lodderstedt <
> tors...@lodderstedt.net> wrote:
>
>> Hi all,
>>
>> my prioritization is driven by the goal to make OAuth the authorization
>> framework of choice for any internet standard protocol, such as WebDAV,
>> IMAP, SMTP or SIP. So let me first explain what is missing from my point of
>> view and explain some thoughts how to fill the gaps.
>>
>> A standard protocol is defined in terms of resource types and messages by
>> a body (e.g. IETF, OIDF, OMA), (hopefully) implemented in many places, and
>> used by different but deployment-independent clients. OAuth-based protocol
>> specifications must also define scope values (e.g. read, write, send) and
>> their relation to the resource types and messages. The different deployments
>> expose the standard protocol on different resource server endpoints. In my
>> opinion, it is fundamental to clearly distinguish scope values
>> (standardized, static) and  resource server addresses (deployment specific)
>> and to manage their relationships. The current scope definition is much to
>> weak and insufficient. Probably, the UMA concepts of hosts, resources sets,
>> and corresponding scopes could be adopted for that purpos

[OAUTH-WG] Publication requested for draft-ietf-oauth-v2-bearer-12

[Hannes Tschofenig]

Hi Stephen,

the OAuth working group requests publication of draft-ietf-oauth-v2-bearer-12 
as Proposed Standard.

Here is the write-up for the document.

---

Document Shepherd Write-Up for draft-ietf-oauth-v2-bearer-12

  (1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd personally reviewed this version of the 
document and, in particular, does he or she believe this 
version is ready for forwarding to the IESG for publication? 

The document shepherd is Hannes Tschofenig. I have personally reviewed the 
document and I think it is ready for going forward. 

  (1.b) Has the document had adequate review both from key WG members 
and from key non-WG members? Does the Document Shepherd have 
any concerns about the depth or breadth of the reviews that 
have been performed?  

The document received a number of reviews from the working group but also 
from members outside the working group, including security reviews.  

  (1.c) Does the Document Shepherd have concerns that the document 
needs more review from a particular or broader perspective, 
e.g., security, operational complexity, someone familiar with 
AAA, internationalization or XML? 

The document was reviewed by Julian Reschke for HTTP related content. 
Changes to the document have been made in response to his review.

There is still disagreement between Julian and working 
group members regarding two issues concerning encoding. While the 
shepherd feels comfortable going forward with the specification to
the IESG wider IETF review may provide additional feedback.

One issue is related to the encoding of the scope attribute in context 
of HTTP authentication parameters:

https://www.ietf.org/mail-archive/web/oauth/current/msg07733.html
https://www.ietf.org/mail-archive/web/oauth/current/msg07734.html
https://www.ietf.org/mail-archive/web/oauth/current/msg07739.html

The other comment by Julian is related to the form encoding, as 
described here: 
https://www.ietf.org/mail-archive/web/oauth/current/msg07731.html


  (1.d) Does the Document Shepherd have any specific concerns or 
issues with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he 
or she is uncomfortable with certain parts of the document, or 
has concerns whether there really is a need for it. In any 
event, if the WG has discussed those issues and has indicated 
that it still wishes to advance the document, detail those 
concerns here. Has an IPR disclosure related to this document 
been filed? If so, please include a reference to the 
disclosure and summarize the WG discussion and conclusion on 
this issue. 

I have no concerns regarding this document but would like to appreciate
feedback from the wider IETF community on the issues raised under 
item 1.c.  

  (1.e) How solid is the WG consensus behind this document? Does it 
represent the strong concurrence of a few individuals, with 
others being silent, or does the WG as a whole understand and 
agree with it?   

There solid consensus behind this document from the working group.

  (1.f) Has anyone threatened an appeal or otherwise indicated extreme 
discontent? If so, please summarise the areas of conflict in 
separate email messages to the Responsible Area Director. (It 
should be in a separate email because this questionnaire is 
entered into the ID Tracker.) 

Nobody had shown extreme discontent. 

  (1.g) Has the Document Shepherd personally verified that the 
document satisfies all ID nits? (See the Internet-Drafts Checklist 
and http://tools.ietf.org/tools/idnits/). Boilerplate checks are 
not enough; this check needs to be thorough. Has the document 
met all formal review criteria it needs to, such as the MIB 
Doctor, media type and URI type reviews? 

I have verified the document. The idnits tool gives a warning about
the RFC 2119 boilerplate, and that warning is incorrect.

  (1.h) Has the document split its references into normative and 
informative? Are there normative references to documents that 
are not ready for advancement or are otherwise in an unclear 
state? If such normative references exist, what is the 
strategy for their completion? Are there normative references 
that are downward references, as described in [RFC3967]? If 
so, list these downward references to support the Area 
Director in the Last Call procedure for them [RFC3967]. 

The references are split into normative and informative references.  

There is one downref to RFC 2818. 

  (1.i) Has the Document Shepherd verified that the document IANA 
consideration section exists and is consistent with the bo