Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 11th February 2013

[William Mills]

I fundamentally disagree with that too.  OAuth 2 is the *framework*, one which 
supports multiple token types.  Bearer tokens were the first credential type 
defined.

OAuth 1.0a also requires HTTPS transport for authentication and getting the 
token.

There are  real use cases for tokens usable over plain text with integrity 
protection.

-bill



 From: Torsten Lodderstedt 
To: William Mills  
Cc: Mike Jones ; Justin Richer 
; Phil Hunt ; IETF oauth WG 
 
Sent: Thursday, February 14, 2013 10:05 PM
Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 
11th February 2013
 

Hi Bill,

OAuth 2.0 took a different direction by relying on HTTPS to provide the basic 
protection. So the need to have a token, which can be used for service requests 
over plain HTTP is arguable. My understanding of this activity was, the intend 
is to provide additional protection on top of HTTPS.

regards,
Torsten.

Am 15.02.2013 um 02:31 schrieb William Mills :


I disagree with "That was the impediment to OAuth 1.0 adoption that OAuth 2.0 
solved in the first place.", unless "solving" means does not address the need 
for it at all.
>
>
>OAuth 2 does several good things, but it still lacks a defined token type that 
>is safe to user over plain text HTTP.  1.0a solved that.
>
>
>
>
> From: Mike Jones 
>To: Justin Richer ; Phil Hunt  
>Cc: IETF oauth WG  
>Sent: Thursday, February 14, 2013 1:44 PM
>Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 
>11th February 2013
> 
>I'm in favor of reusing the JWT work that this WG is also doing. :-)
>
>I'm pretty skeptical of us inventing another custom scheme for signing HTTP 
>headers.  That was the impediment to OAuth 1.0 adoption that OAuth 2.0 solved 
>in the first place.
>
>                -- Mike
>
>-Original Message-
>From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of 
>Justin Richer
>Sent: Tuesday, February 12, 2013 9:35 AM
>To: Phil Hunt
>Cc: IETF oauth WG
>Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 
>11th February 2013
>
>That's my reading of it as well, Phil, thanks for providing the clarification. 
>One motivator behind using a JSON-based token is to be able to
 re-use some of the great work that the JOSE group is doing but apply it to an 
HTTP payload.
>
>What neither of us want is a token type that requires stuffing all query, 
>header, and other parameters *into* the JSON object itself, which would be a 
>more SOAPy approach.
>
>  -- Justin
>
>On 02/12/2013 12:30 PM, Phil Hunt wrote:
>> Clarification.  I think Justin and I were in agreement that we don't want to 
>> see a format that requires JSON payloads.  We are both interested in a JSON 
>> token used in the authorization header that could be based on a computed 
>> signature of some combination of http headers and body if possible.
>>
>> Phil
>>
>> @independentid
>> www.independentid.com
>> phil.h...@oracle.com
>>
>>
>>
>>
>>
>> On
 2013-02-12, at 1:10 AM, Hannes Tschofenig wrote:
>>
>>> Here are my notes.
>>>
>>> Participants:
>>>
>>> * John Bradley
>>> * Derek Atkins
>>> * Phil Hunt
>>> * Prateek Mishra
>>> * Hannes Tschofenig
>>> * Mike Jones
>>> * Antonio Sanso
>>> * Justin Richer
>>>
>>> Notes:
>>>
>>> My slides are available here: 
>>> http://www.tschofenig.priv.at/OAuth2-Security-11Feb2013.ppt
>>>
>>> Slide #2 summarizes earlier discussions during the conference calls.
>>>
>>> -- HTTP vs. JSON
>>>
>>> Phil noted that he does not like to use the MAC Token draft as a starting 
>>> point because it does not re-use any of the work done in the JOSE working 
>>> group and in particular all the libraries that are available today. He 
>>> mentioned that earlier attempts to write the MAC Token code lead to
 problems for implementers.
>>>
>>> Justin responded that he does not agree with using JSON as a transport 
>>> mechanism since this would replicate a SOAP style.
>>>
>>> Phil noted that he wants to send JSON but the signature shall be computed 
>>> over the HTTP header field.
>>>
>>> -- Flexibility for the keyed message digest computation
>>>
>>>  From earlier discussion it was clear that the conference call participants 
>>>wanted more flexibility regarding the keyed message digest computation. For 
>>>this purpose Hannes presented the DKIM based approach, which allows 
>>>selective header fields to be included in the digest. This is shown in slide 
>>>#4.
>>>
>>> After some discussion the conference call participants thought that this 
>>> would meet their needs. Further investigations would still be useful to 
>>> determine the degree of failed HMAC calculations due to HTTP proxies 
>>> modifying the
 content.
>>>
>>> -- Key Distribution
>>>
>>> Hannes presented the open issue regarding the choice of key 
>>> distribution. Slides #6-#8 present three techniques and Hannes asked 
>>> for feedback regarding the preferred style. Justin and other

Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 11th February 2013

[Torsten Lodderstedt]

Hi Bill,

OAuth 2.0 took a different direction by relying on HTTPS to provide the basic 
protection. So the need to have a token, which can be used for service requests 
over plain HTTP is arguable. My understanding of this activity was, the intend 
is to provide additional protection on top of HTTPS.

regards,
Torsten.

Am 15.02.2013 um 02:31 schrieb William Mills :

> I disagree with "That was the impediment to OAuth 1.0 adoption that OAuth 2.0 
> solved in the first place.", unless "solving" means does not address the need 
> for it at all.
> 
> OAuth 2 does several good things, but it still lacks a defined token type 
> that is safe to user over plain text HTTP.  1.0a solved that.
> 
> From: Mike Jones 
> To: Justin Richer ; Phil Hunt  
> Cc: IETF oauth WG  
> Sent: Thursday, February 14, 2013 1:44 PM
> Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 
> 11th February 2013
> 
> I'm in favor of reusing the JWT work that this WG is also doing. :-)
> 
> I'm pretty skeptical of us inventing another custom scheme for signing HTTP 
> headers.  That was the impediment to OAuth 1.0 adoption that OAuth 2.0 solved 
> in the first place.
> 
> -- Mike
> 
> -Original Message-
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of 
> Justin Richer
> Sent: Tuesday, February 12, 2013 9:35 AM
> To: Phil Hunt
> Cc: IETF oauth WG
> Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 
> 11th February 2013
> 
> That's my reading of it as well, Phil, thanks for providing the 
> clarification. One motivator behind using a JSON-based token is to be able to 
> re-use some of the great work that the JOSE group is doing but apply it to an 
> HTTP payload.
> 
> What neither of us want is a token type that requires stuffing all query, 
> header, and other parameters *into* the JSON object itself, which would be a 
> more SOAPy approach.
> 
>   -- Justin
> 
> On 02/12/2013 12:30 PM, Phil Hunt wrote:
> > Clarification.  I think Justin and I were in agreement that we don't want 
> > to see a format that requires JSON payloads.  We are both interested in a 
> > JSON token used in the authorization header that could be based on a 
> > computed signature of some combination of http headers and body if possible.
> >
> > Phil
> >
> > @independentid
> > www.independentid.com
> > phil.h...@oracle.com
> >
> >
> >
> >
> >
> > On 2013-02-12, at 1:10 AM, Hannes Tschofenig wrote:
> >
> >> Here are my notes.
> >>
> >> Participants:
> >>
> >> * John Bradley
> >> * Derek Atkins
> >> * Phil Hunt
> >> * Prateek Mishra
> >> * Hannes Tschofenig
> >> * Mike Jones
> >> * Antonio Sanso
> >> * Justin Richer
> >>
> >> Notes:
> >>
> >> My slides are available here: 
> >> http://www.tschofenig.priv.at/OAuth2-Security-11Feb2013.ppt
> >>
> >> Slide #2 summarizes earlier discussions during the conference calls.
> >>
> >> -- HTTP vs. JSON
> >>
> >> Phil noted that he does not like to use the MAC Token draft as a starting 
> >> point because it does not re-use any of the work done in the JOSE working 
> >> group and in particular all the libraries that are available today. He 
> >> mentioned that earlier attempts to write the MAC Token code lead to 
> >> problems for implementers.
> >>
> >> Justin responded that he does not agree with using JSON as a transport 
> >> mechanism since this would replicate a SOAP style.
> >>
> >> Phil noted that he wants to send JSON but the signature shall be computed 
> >> over the HTTP header field.
> >>
> >> -- Flexibility for the keyed message digest computation
> >>
> >>  From earlier discussion it was clear that the conference call 
> >> participants wanted more flexibility regarding the keyed message digest 
> >> computation. For this purpose Hannes presented the DKIM based approach, 
> >> which allows selective header fields to be included in the digest. This is 
> >> shown in slide #4.
> >>
> >> After some discussion the conference call participants thought that this 
> >> would meet their needs. Further investigations would still be useful to 
> >> determine the degree of failed HMAC calculations due to HTTP proxies 
> >> modifying the content.
> >>
> >> -- Key Distribution
> >>
> >> Hannes presented the open issue regarding the choice of key 
> >> distribution. Slides #6-#8 present three techniques and Hannes asked 
> >> for feedback regarding the preferred style. Justin and others didn't 
> >> see the need to decide on one mechanism - they wanted to keep the 
> >> choice open. Derek indicated that this will not be an acceptable 
> >> approach. Since the resource server and the authorization server may, 
> >> in the OAuth 2.0 framework, be entities produced by different vendors 
> >> there is an interoperability need. Justin responded that he disagrees 
> >> and that the resource server needs to understand the access token and 
> >> referred to the recent draft submission for the token introspection 
> >> endpoint. Derek indic

Re: [OAUTH-WG] comments on draft-ietf-oauth-saml2-bearer-15

[Brian Campbell]

Thanks for the feedback Prateek. I've tried to address some of you comments
and questions inline below.


On Wed, Feb 13, 2013 at 3:53 PM, Prateek Mishra
wrote:

> It would be helpful if the draft identified the various cases that are
> intended to be supported. For example,
> in draft-ietf-oauth-assertions-**10, there is a helpful distinction made
> between "Client acting on behalf of a user" vs.
> "Client Action on behalf of an anonymous user" (vs. even more advanced
> use-cases). Otherwise, folks
> have a hard time figuring out the pieces they need to implement and the
> required behavior.
>

The guidance in §6 of draft-ietf-oauth-assertions-10 provides some
particular details of the more general general cases and they apply here as
well as the JWT draft. I'd like to avoid repeating the text and bloating
the documents.


>
> It feels like Section 3 speaks to all of these cases simultaneously. I
> think this is confusing and
> our developers have raised some questions about it.
>

It's not really intended to speak to the cases so much as provide the
required processing rules to validate the assertion in a reasonably secure
way. There is some simultaneous treatment of the client authentication case
and the authorization grant case because they have much more in common than
they have that's different. I can make a pass at better pointing out where
the differences are.


>
> BTW, it would also help if the rules in Section 3 were numbered.
>

I'll see what I can do. I assume it's possible with the xml2rfc markup but
have never done it.


>
> 1) For the case where we have "Client acting on behalf of user" - this
> case seems to be where we
> have something like a SAML SSO assertion - complete with Subject
> identifying the
> "authorized accessor or delegate". The Client offers this bearer
> instrument as an access grant and the Authorization
> server understands that its "acting on behalf a user".
>
> a) As the SAML assertion is a bearer instrument and can be stolen, the
> authorization server should insist on client credentials being present.
> In other words, the client should be confidential. What is the value in
> permitting a public client to participate in this exchange?
>

Very similar to SAML Web SSO where the client (HTTP user agent browser in
that case) is unidentified and the bearer assertion is the sole token
provided to identify/authenticate the subject and gain access. In some
cases there is a quite a bit of value in not having to provision or manage
the clients.


>
> b) Further, as part of its processing rules, once the client has been
> authenticated
> the authorization server should determine whether the particular client
> has the right to present the SAML bearer assertion.
>

An AS is free to deploy that kind of policy as needed for the deployment or
product. But the spec intentionally does not dictate any such policy.  And
intentionally allows for unidentified clients.


>
> c)  What is the value of including an AuthNStatement? Specifically, what
> does the Authorization server understand by its
> presence or absence? What is the guidance to deployers? Should they
> require end-user authentication to have taken place?
>
>
It's intended to convey whether or not the issuer actually authenticated
the subject or not. It's a distinction that, based on some conversations
I'd had, seemed like it might be useful for some. But much existing SAML
software doesn't work that way currently, which is why there's not a MUST
there. I'm trying to accommodate existing practice, within reason, while
also provide potentially useful functionality.


> 2) Bullet 5 (counting from the bottom of Section 3) references a more
> advanced use case based on a SAML delegation
> model. Is this the ONLY case where AuthNStatement's are allowed to be
> omitted? If so, that should be stated clearly.
>

I've got a SHOULD NOT there. I don't think a MUST is reasonable based on
what I've seen actual deployments do. Please suggest some text, if you
think it can be improved.


>
>  I think this bullet refers to an advanced use-case and should be moved to
> an independent section.
>

I think it's pretty common actually.


>
> I think by "the presenter act autonomously on behalf of the subject" you
> mean something like "Client acts on Behalf of Anonymous Users".
> as identified in draft-ietf-oauth-assertions-**10.
>

No. I mean that the presenter (client) is acting on behalf of the user.
And the user probably isn't present for the transactions. "Autonomous" is a
word that kind of got inherited from the very early OAuth 2.0 drafts (
http://tools.ietf.org/html/draft-ietf-oauth-v2-08#section-1.4.4) and maybe
causes more trouble than it's worth here?


>
> I also found the sentence "The presented SHOULD be identified in the
>  or similar element,.." problematic. Its pretty open ended
> and it seems to me it will be difficult to have an interoperable
> implementation based on this text.
>

I agree that it's confusing and I believe it's

Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 11th February 2013

[William Mills]

I disagree with "That was the impediment to OAuth 1.0 adoption that OAuth 2.0 
solved in the first place.", unless "solving" means does not address the need 
for it at all.

OAuth 2 does several good things, but it still lacks a defined token type that 
is safe to user over plain text HTTP.  1.0a solved that.



 From: Mike Jones 
To: Justin Richer ; Phil Hunt  
Cc: IETF oauth WG  
Sent: Thursday, February 14, 2013 1:44 PM
Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 
11th February 2013
 
I'm in favor of reusing the JWT work that this WG is also doing. :-)

I'm pretty skeptical of us inventing another custom scheme for signing HTTP 
headers.  That was the impediment to OAuth 1.0 adoption that OAuth 2.0 solved 
in the first place.

                -- Mike

-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of 
Justin Richer
Sent: Tuesday, February 12, 2013 9:35 AM
To: Phil Hunt
Cc: IETF oauth WG
Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 
11th February 2013

That's my reading of it as well, Phil, thanks for providing the clarification. 
One motivator behind using a JSON-based token is to be able to re-use some of 
the great work that the JOSE group is doing but apply it to an HTTP payload.

What neither of us want is a token type that requires stuffing all query, 
header, and other parameters *into* the JSON object itself, which would be a 
more SOAPy approach.

  -- Justin

On 02/12/2013 12:30 PM, Phil Hunt wrote:
> Clarification.  I think Justin and I were in agreement that we don't want to 
> see a format that requires JSON payloads.  We are both interested in a JSON 
> token used in the authorization header that could be based on a computed 
> signature of some combination of http headers and body if possible.
>
> Phil
>
> @independentid
> www.independentid.com
> phil.h...@oracle.com
>
>
>
>
>
> On 2013-02-12, at 1:10 AM, Hannes Tschofenig wrote:
>
>> Here are my notes.
>>
>> Participants:
>>
>> * John Bradley
>> * Derek Atkins
>> * Phil Hunt
>> * Prateek Mishra
>> * Hannes Tschofenig
>> * Mike Jones
>> * Antonio Sanso
>> * Justin Richer
>>
>> Notes:
>>
>> My slides are available here: 
>> http://www.tschofenig.priv.at/OAuth2-Security-11Feb2013.ppt
>>
>> Slide #2 summarizes earlier discussions during the conference calls.
>>
>> -- HTTP vs. JSON
>>
>> Phil noted that he does not like to use the MAC Token draft as a starting 
>> point because it does not re-use any of the work done in the JOSE working 
>> group and in particular all the libraries that are available today. He 
>> mentioned that earlier attempts to write the MAC Token code lead to problems 
>> for implementers.
>>
>> Justin responded that he does not agree with using JSON as a transport 
>> mechanism since this would replicate a SOAP style.
>>
>> Phil noted that he wants to send JSON but the signature shall be computed 
>> over the HTTP header field.
>>
>> -- Flexibility for the keyed message digest computation
>>
>>  From earlier discussion it was clear that the conference call participants 
>>wanted more flexibility regarding the keyed message digest computation. For 
>>this purpose Hannes presented the DKIM based approach, which allows selective 
>>header fields to be included in the digest. This is shown in slide #4.
>>
>> After some discussion the conference call participants thought that this 
>> would meet their needs. Further investigations would still be useful to 
>> determine the degree of failed HMAC calculations due to HTTP proxies 
>> modifying the content.
>>
>> -- Key Distribution
>>
>> Hannes presented the open issue regarding the choice of key 
>> distribution. Slides #6-#8 present three techniques and Hannes asked 
>> for feedback regarding the preferred style. Justin and others didn't 
>> see the need to decide on one mechanism - they wanted to keep the 
>> choice open. Derek indicated that this will not be an acceptable 
>> approach. Since the resource server and the authorization server may, 
>> in the OAuth 2.0 framework, be entities produced by different vendors 
>> there is an interoperability need. Justin responded that he disagrees 
>> and that the resource server needs to understand the access token and 
>> referred to the recent draft submission for the token introspection 
>> endpoint. Derek indicated that the resource server has to understand 
>> the content of the access token and the token introspection endpoint 
>> just pushes the problem around: the resource server has to send the 
>> access token to the authorization server and then the resource server 
>> gets the result back (which he the
n
>    a
>> gain needs to understand) in order to make a meaningful authorization 
>> decision.
>>
>> Everyone agreed that the client must receive the session key from the 
>> authorization server and that this approach has to be standardized. It was 
>> also agreed that this 

Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 11th February 2013

[Mike Jones]

I'm in favor of reusing the JWT work that this WG is also doing. :-)

I'm pretty skeptical of us inventing another custom scheme for signing HTTP 
headers.  That was the impediment to OAuth 1.0 adoption that OAuth 2.0 solved 
in the first place.

-- Mike

-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of 
Justin Richer
Sent: Tuesday, February 12, 2013 9:35 AM
To: Phil Hunt
Cc: IETF oauth WG
Subject: Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 
11th February 2013

That's my reading of it as well, Phil, thanks for providing the clarification. 
One motivator behind using a JSON-based token is to be able to re-use some of 
the great work that the JOSE group is doing but apply it to an HTTP payload.

What neither of us want is a token type that requires stuffing all query, 
header, and other parameters *into* the JSON object itself, which would be a 
more SOAPy approach.

  -- Justin

On 02/12/2013 12:30 PM, Phil Hunt wrote:
> Clarification.  I think Justin and I were in agreement that we don't want to 
> see a format that requires JSON payloads.  We are both interested in a JSON 
> token used in the authorization header that could be based on a computed 
> signature of some combination of http headers and body if possible.
>
> Phil
>
> @independentid
> www.independentid.com
> phil.h...@oracle.com
>
>
>
>
>
> On 2013-02-12, at 1:10 AM, Hannes Tschofenig wrote:
>
>> Here are my notes.
>>
>> Participants:
>>
>> * John Bradley
>> * Derek Atkins
>> * Phil Hunt
>> * Prateek Mishra
>> * Hannes Tschofenig
>> * Mike Jones
>> * Antonio Sanso
>> * Justin Richer
>>
>> Notes:
>>
>> My slides are available here: 
>> http://www.tschofenig.priv.at/OAuth2-Security-11Feb2013.ppt
>>
>> Slide #2 summarizes earlier discussions during the conference calls.
>>
>> -- HTTP vs. JSON
>>
>> Phil noted that he does not like to use the MAC Token draft as a starting 
>> point because it does not re-use any of the work done in the JOSE working 
>> group and in particular all the libraries that are available today. He 
>> mentioned that earlier attempts to write the MAC Token code lead to problems 
>> for implementers.
>>
>> Justin responded that he does not agree with using JSON as a transport 
>> mechanism since this would replicate a SOAP style.
>>
>> Phil noted that he wants to send JSON but the signature shall be computed 
>> over the HTTP header field.
>>
>> -- Flexibility for the keyed message digest computation
>>
>>  From earlier discussion it was clear that the conference call participants 
>> wanted more flexibility regarding the keyed message digest computation. For 
>> this purpose Hannes presented the DKIM based approach, which allows 
>> selective header fields to be included in the digest. This is shown in slide 
>> #4.
>>
>> After some discussion the conference call participants thought that this 
>> would meet their needs. Further investigations would still be useful to 
>> determine the degree of failed HMAC calculations due to HTTP proxies 
>> modifying the content.
>>
>> -- Key Distribution
>>
>> Hannes presented the open issue regarding the choice of key 
>> distribution. Slides #6-#8 present three techniques and Hannes asked 
>> for feedback regarding the preferred style. Justin and others didn't 
>> see the need to decide on one mechanism - they wanted to keep the 
>> choice open. Derek indicated that this will not be an acceptable 
>> approach. Since the resource server and the authorization server may, 
>> in the OAuth 2.0 framework, be entities produced by different vendors 
>> there is an interoperability need. Justin responded that he disagrees 
>> and that the resource server needs to understand the access token and 
>> referred to the recent draft submission for the token introspection 
>> endpoint. Derek indicated that the resource server has to understand 
>> the content of the access token and the token introspection endpoint 
>> just pushes the problem around: the resource server has to send the 
>> access token to the authorization server and then the resource server 
>> gets the result back (which he the
 n
>a
>> gain needs to understand) in order to make a meaningful authorization 
>> decision.
>>
>> Everyone agreed that the client must receive the session key from the 
>> authorization server and that this approach has to be standardized. It was 
>> also agreed that this is a common approach among all three key distribution 
>> mechanisms.
>>
>> Hannes asked the participants to think about their preference.
>>
>> The questions regarding key naming and the indication for the intended 
>> resource server the client wants to talk to have been postponed.
>>
>> Ciao
>> Hannes
>>
>>
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
> ___
> OAuth mailing list
> OAuth@ietf.

Re: [OAUTH-WG] Fwd: New Version Notification for draft-richer-oauth-introspection-02.txt

[Donald F Coffin]

Does the term "Active" help clarify the meaning but still confirm to your
intention, Justin?

 

Best regards,

Don

Donald F. Coffin

Founder/CTO

 

REMI Networks

22751 El Prado Suite 6216

Rancho Santa Margarita, CA  92688-3836

 

Phone:  (949) 636-8571

Email:
donald.cof...@reminetworks.com

 

From: Justin Richer [mailto:jric...@mitre.org] 
Sent: Thursday, February 14, 2013 8:16 AM
To: Prabath Siriwardena
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Fwd: New Version Notification for
draft-richer-oauth-introspection-02.txt

 

That much I can at least do. I'd be happy with another term if there was a
good one we could drop in its place without changing the intended semantics.

 -- Justin

On 02/14/2013 10:57 AM, Prabath Siriwardena wrote:

Not quite convinced :-) Valid has a meaning attached to that.. 

 

In case we are going ahead with this please define it clearly in the draft -
with the one you shared in this thread.

 

Thanks & regards,

-Prabath

On Thu, Feb 14, 2013 at 8:16 PM, Justin Richer  wrote:

 

On 02/14/2013 09:37 AM, Prabath Siriwardena wrote:

The definition of valid is bit ambiguous in the draft...

 

Okay.. If that is the definition... and if we beak that in to parts...

 

"it hasn't expired" : In the response it self we have parameter for
issued_at and and expires_at - so whether the token is not expired or not
can even be derived at the requestor's end.

 

If the token isn't good anymore, it doesn't matter when it was issued or
when it was expired, just that it has. 






 

"token was issued from here" : For this IMO we need to send an error code.
Requestor has picked the wrong AS.

We don't know if it came from another AS or if someone's just making things
up. Either way it's not a good token. 






 

The remaining is  "revoked".. That is why I proposed earlier - we better
have an attribute "revoked" - instead of "valid" in the response..

 

The end result of all three is the same: either the token is good, or it
isn't. I think it's much simpler and more useful to leave it at that.

 -- Justin 






 

WDYT...?

 

Thanks & regards,

-Prabath

 

 

On Thu, Feb 14, 2013 at 7:58 PM, Justin Richer  wrote:

Because it will be the one that issued the token in the first place. 

Validity means "token was issued from here, it hasn't been revoked, it
hasn't expired". 

 -- Justin 

 

On 02/14/2013 09:28 AM, Prabath Siriwardena wrote:

Okay. With out knowing the type of the token how can the AS validate the
token ? What is meant by the validity there? 

 

Thanks & regards,

-Prabath

On Thu, Feb 14, 2013 at 7:55 PM, Justin Richer  wrote:

OK, I don't see the utility in that at all. What would it accomplish?

 -- Justin 

 

On 02/14/2013 09:25 AM, Prabath Siriwardena wrote:

To make it clear - my suggestion is to add token_type_hint to the
introspection request. It can be from client to AS or from RS to AS. 

 

Then AS can decide whether the provided token is valid or not and include
"valid" attribute in the introspection response.

 

Thanks & regards,

-Prabath

On Thu, Feb 14, 2013 at 7:52 PM, Prabath Siriwardena 
wrote:

Both the client and the resource owner should be aware of the token type. 

 

My argument is, if the authorization server to decide whether the token is
valid or not ( irrespective of who asked the question) - AS needs to know
the token type - because to validate a token AS should know the token type.

 

The token type could be, bearer or MAC or any other token type.

 

Thanks & regards,

-Prabath 

 

On Thu, Feb 14, 2013 at 7:33 PM, Justin Richer  wrote:

What exactly are you suggesting be added to introspection? The
"token_type_hint" is from the client to the server, but what you've asked
for in terms of "token type" is from the server to the client. And there was
never an answer to what exactly is meant by "token type" in this case,
particularly because you seem to want to call out things like SAML and
Bearer as separate types. 

 -- Justin 





On 02/14/2013 06:59 AM, Prabath Siriwardena wrote:

I noticed that the latest Token Revocation draft [1] has introduced the
parameter "token_type_hint". I would suggest the same here, as that would
make what is meant by "valid" much clear.. 

 

[1]:  
http://tools.ietf.org/html/draft-ietf-oauth-revocation-05

 

Thanks & regards,

-Prabath

On Tue, Feb 12, 2013 at 9:35 PM, Prabath Siriwardena 
wrote:

Hi Justin, 

 

I doubt whether valid_token would make a difference..?

 

My initial argument is what is the validation criteria..? Validation
criteria depends on the token_type..

 

If we are talking only about metadata - then I believe "revoked", "expired"
would be more meaningful..

 

Thanks & regards,

-Prabath 

 

On Tue, Feb 12, 2013 at 7:53 PM, Justin Richer  wrote:

OK, I can see the wisdom in changing this term. 

I picked "valid" because I wanted a simple "boolean" value that would
req

Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 11th February 2013

[Justin Richer]

Prateek,

My point was that a public client could very easily and safely be issued 
a secret in the form of an OAuth token. This includes any type of 
signing key that the MAC/etc token would want to use. What public 
client's can't have are configuration-time keys, like a client_secret. 
It's important to not conflate the two.


 -- Justin

On 02/14/2013 02:20 PM, Prateek Mishra wrote:
Justin - my comment was scoped to *key distribution* - not to the 
general use of public clients.


I was wondering how one can distribute keys or have key agreement 
between an AS and a client, if there is no existing trust relationship 
between them. Maybe there is some
clever crypto way of achieving this, but I personally dont understand 
how this might happen.


- prateek



2) Regarding (symmetric) key distribution, dont we need some kind 
of existing trust relationship between the client and AS to make 
this possible? I guess it
would be enough to require use of a "confidential" client, that 
would make it possible for the two parties to agree on a session 
key at the point where an access token

is  issued by the AS.
That's a very good question. I have not formed an option about this 
issue yet particularly given the recent capability to dynamically 
register clients.


I don't think that signing tokens should require confidential 
clients. This was one of the implementation issues with OAuth 1, as 
it required a "consumer_secret" at all times. This led to Google 
telling people to use "anonymous" as the "consumer_secret" for what 
were effectively public clients. Even with dynamic registration, 
there's still a place for public clients, in my opinion.






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

Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 11th February 2013

[Prateek Mishra]

Justin - my comment was scoped to *key distribution* - not to the 
general use of public clients.


I was wondering how one can distribute keys or have key agreement 
between an AS and a client, if there is no existing trust relationship 
between them. Maybe there is some
clever crypto way of achieving this, but I personally dont understand 
how this might happen.


- prateek



2) Regarding (symmetric) key distribution, dont we need some kind of 
existing trust relationship between the client and AS to make this 
possible? I guess it
would be enough to require use of a "confidential" client, that 
would make it possible for the two parties to agree on a session key 
at the point where an access token

is  issued by the AS.
That's a very good question. I have not formed an option about this 
issue yet particularly given the recent capability to dynamically 
register clients.


I don't think that signing tokens should require confidential clients. 
This was one of the implementation issues with OAuth 1, as it required 
a "consumer_secret" at all times. This led to Google telling people to 
use "anonymous" as the "consumer_secret" for what were effectively 
public clients. Even with dynamic registration, there's still a place 
for public clients, in my opinion.




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

Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 11th February 2013

[Prateek Mishra]

Regarding the question of AS to RS communication, I think capturing it 
is a reasonable task but not one essential to this activity.


So my view would be to exclude it from consideration in this groups 
activity. We have many use-cases where support for confirmation that goes
beyond the currently supported bearer model would be valuable. In these 
cases, the AS and RS belong to the same administrative domain.


- prateek

Hi Prateek,


thanks for your questions.


On Feb 13, 2013, at 6:13 PM, Prateek Mishra wrote:


Hannes,

1) Its not clear to me that we need  to specify exchanges between the AS and 
the RS as part of this work. The core specification leaves this
unspecified. There could be many different ways that the AS and RS collaborate 
to validate signatures in messages received from the client.

It depends what the group wants to accomplish. So far, I thought that the goal 
was to offer the ability to provide a sufficient description in our 
specifications so that the authorization server and the resource server can be 
provided by different vendors and that they still interoperate.

The group may have changed their mind in the meanwhile.

What is your view?



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

Re: [OAUTH-WG] Registration: RESTful client lifecycle management

[John Bradley]

On 2013-02-14, at 11:20 AM, Justin Richer  wrote:

> 
> On 02/14/2013 09:05 AM, John Bradley wrote:
>> I agree with Tim that is the behaviour I would  expect to see with DELETE 
>> though I have a rd time seeing a server ever honouring it.
>> 
>> I guess that we need to clarify what happens with PUT and claims the server 
>> has defaults for, perhaps some that are not changeable by the client.   
>> 
>> Is not including a claim in a PUT the same as not including it in 
>> registration, and it is set to the default.  
>> If you want to set a claim to null then you must explicitly include the 
>> claim with null as the value. That is the previous logic we had for replace 
>> as the client wasn't getting back all the config in the response and 
>> couldn't know about defaults it wasn't setting.
>> 
>> Perhaps PUT causes unsent claims to be interpreted as if they are sent with 
>> a null value (I think that is a likely to cause tears personally).
>> 
>> In ether case the client is not deleted and can still be recovered and the 
>> client_id and associated permissions are still active.
> 
> What I had in mind from this conversation is something like this:
> 
> When sending an update, a client MUST send all metadata fields returned
> from the server in its initial registration or previous read or update
> call, including its client_id. A server MAY replace any missing or
> invalid fields with default values, or it MAY return an error as
> described in the Error Response section. A server MUST return all
> provisioned fields in its response. A server MUST NOT change the
> client_id field. A server MAY change the client_secret and/or
> refresh_access_token fields.

Yes that covers it.
> 
>> 
>> DELETE to be used correctly is I think going to delete the client_id and all 
>> associated tokens and cause a ripple effect in removing grants associated 
>> with that client_id.  
> 
> This is how I would interpret it as well. It's de-provisioning the
> client, not resetting it.

That is what I would expect I don't know if it is a good idea, and adds to the 
size of the spec.   Having a not supported response is better but, I don't have 
a good feeling about it yet.


> 
> -- Justin
> 
>> 
>> It is a big difference and understanding what a AS is supposed to do to 
>> delete a client still seems a touch vague to me.   I understand the http 
>> verb but there is more to it than that if we want interoperability.
>> 
>> John
>> 
>> On 2013-02-14, at 12:31 AM, Nat Sakimura  wrote:
>> 
>>> I thought your concern about DELETE was whether the client should be
>>> allowed to erase the registration data.
>>> I thought PUT with an empty values would achieve a similar effect.
>>> Or did you mean that with PUT, the server default kicks in and
>>> parameters are set to the defaults?
>>> If that is the case, they are quite different, I agree.
>>> 
>>> On the effect of DELETE, +1 to Tim's comment.
>>> 
>>> Nat
>>> 
>>> 2013/2/14 John Bradley :
 DELETE is removing the record not resetting it to defaults.  They are 
 quite diffrent.
 
 I want to agree on what the expected behaviour of DELETE is.   I think we 
 have agreement on PUT and POST.
 
 The general not in that a client can DELETE it's record is a implication I 
 don't like.  I think that is for the server to decide and if it is not 
 actually deleting it then DELETE is the wrong verb to use.
 
 John B.
 
 On 2013-02-13, at 3:31 PM, Nat Sakimura  wrote:
 
> Generally speaking, mapping PUT to replace and POST to change is an
> acceptable practice so I am fine with it.
> 
> Now, what I still do not understand is why you think it is fine to do
> PUT or POST and not DELETE. Doing PUT with empty content is almost the
> same as DELETE. Could you explain?
> 
> =nat via iPhone
> 
> Feb 14, 2013 0:10、John Bradley  のメッセージ:
> 
>> I am not violently opposed to PUT as a option that completely replaces 
>> the resource setting all unsent claims back to the defaults.
>> 
>> I don't have a good feeling about DELETE,  I think we still need more 
>> discussion on what it means, what privileges it takes to invoke it etc.
>> It could be a bad thing if we get wrong or is not implemented 
>> consistently.
>> 
>> Personally I don't think a client should ever be able to DELETE it's 
>> record.
>> 
>> I think marking a client_id as pending provisioning, suspended,  revoked 
>> etc is better and that can be done with a claim in the update endpoint.
>> 
>> It should only be the server that deletes a record after satisfying it's 
>> audit requirements.
>> 
>> John B.
>> 
>> On 2013-02-13, at 12:00 PM, Justin Richer  wrote:
>> 
>>> Would it be reasonable to mark the PUT and DELETE methods as optional 
>>> for the server to implement, but with defined semantics if they do? I 
>>> want to keep GET and POST(create) as ma

Re: [OAUTH-WG] Registration: RESTful client lifecycle management

[Justin Richer]

On 02/14/2013 09:05 AM, John Bradley wrote:
> I agree with Tim that is the behaviour I would  expect to see with DELETE 
> though I have a rd time seeing a server ever honouring it.
>
> I guess that we need to clarify what happens with PUT and claims the server 
> has defaults for, perhaps some that are not changeable by the client.   
>
> Is not including a claim in a PUT the same as not including it in 
> registration, and it is set to the default.  
> If you want to set a claim to null then you must explicitly include the claim 
> with null as the value. That is the previous logic we had for replace as the 
> client wasn't getting back all the config in the response and couldn't know 
> about defaults it wasn't setting.
>
> Perhaps PUT causes unsent claims to be interpreted as if they are sent with a 
> null value (I think that is a likely to cause tears personally).
>
> In ether case the client is not deleted and can still be recovered and the 
> client_id and associated permissions are still active.

What I had in mind from this conversation is something like this:

When sending an update, a client MUST send all metadata fields returned
from the server in its initial registration or previous read or update
call, including its client_id. A server MAY replace any missing or
invalid fields with default values, or it MAY return an error as
described in the Error Response section. A server MUST return all
provisioned fields in its response. A server MUST NOT change the
client_id field. A server MAY change the client_secret and/or
refresh_access_token fields.

>
> DELETE to be used correctly is I think going to delete the client_id and all 
> associated tokens and cause a ripple effect in removing grants associated 
> with that client_id.  

This is how I would interpret it as well. It's de-provisioning the
client, not resetting it.

-- Justin

>
> It is a big difference and understanding what a AS is supposed to do to 
> delete a client still seems a touch vague to me.   I understand the http verb 
> but there is more to it than that if we want interoperability.
>
> John
>
> On 2013-02-14, at 12:31 AM, Nat Sakimura  wrote:
>
>> I thought your concern about DELETE was whether the client should be
>> allowed to erase the registration data.
>> I thought PUT with an empty values would achieve a similar effect.
>> Or did you mean that with PUT, the server default kicks in and
>> parameters are set to the defaults?
>> If that is the case, they are quite different, I agree.
>>
>> On the effect of DELETE, +1 to Tim's comment.
>>
>> Nat
>>
>> 2013/2/14 John Bradley :
>>> DELETE is removing the record not resetting it to defaults.  They are quite 
>>> diffrent.
>>>
>>> I want to agree on what the expected behaviour of DELETE is.   I think we 
>>> have agreement on PUT and POST.
>>>
>>> The general not in that a client can DELETE it's record is a implication I 
>>> don't like.  I think that is for the server to decide and if it is not 
>>> actually deleting it then DELETE is the wrong verb to use.
>>>
>>> John B.
>>>
>>> On 2013-02-13, at 3:31 PM, Nat Sakimura  wrote:
>>>
 Generally speaking, mapping PUT to replace and POST to change is an
 acceptable practice so I am fine with it.

 Now, what I still do not understand is why you think it is fine to do
 PUT or POST and not DELETE. Doing PUT with empty content is almost the
 same as DELETE. Could you explain?

 =nat via iPhone

 Feb 14, 2013 0:10、John Bradley  のメッセージ:

> I am not violently opposed to PUT as a option that completely replaces 
> the resource setting all unsent claims back to the defaults.
>
> I don't have a good feeling about DELETE,  I think we still need more 
> discussion on what it means, what privileges it takes to invoke it etc.
> It could be a bad thing if we get wrong or is not implemented 
> consistently.
>
> Personally I don't think a client should ever be able to DELETE it's 
> record.
>
> I think marking a client_id as pending provisioning, suspended,  revoked 
> etc is better and that can be done with a claim in the update endpoint.
>
> It should only be the server that deletes a record after satisfying it's 
> audit requirements.
>
> John B.
>
> On 2013-02-13, at 12:00 PM, Justin Richer  wrote:
>
>> Would it be reasonable to mark the PUT and DELETE methods as optional 
>> for the server to implement, but with defined semantics if they do? I 
>> want to keep GET and POST(create) as mandatory, as I think that's the 
>> minimal set of functionality required.
>>
>> -- Justin
>>
>> On 02/11/2013 08:51 PM, John Bradley wrote:
>>> I would always include the client_id on update.
>>>
>>> I think it is also us full to have other tokens used at the update 
>>> endpoint.  I can see the master token used to update all the clients it 
>>> has registered as part of API managem

Re: [OAUTH-WG] Registration: RESTful client lifecycle management

[John Bradley]

I agree with Tim that is the behaviour I would  expect to see with DELETE 
though I have a rd time seeing a server ever honouring it.

I guess that we need to clarify what happens with PUT and claims the server has 
defaults for, perhaps some that are not changeable by the client.   

Is not including a claim in a PUT the same as not including it in registration, 
and it is set to the default.  
If you want to set a claim to null then you must explicitly include the claim 
with null as the value. That is the previous logic we had for replace as the 
client wasn't getting back all the config in the response and couldn't know 
about defaults it wasn't setting.

Perhaps PUT causes unsent claims to be interpreted as if they are sent with a 
null value (I think that is a likely to cause tears personally).

In ether case the client is not deleted and can still be recovered and the 
client_id and associated permissions are still active.

DELETE to be used correctly is I think going to delete the client_id and all 
associated tokens and cause a ripple effect in removing grants associated with 
that client_id.  

It is a big difference and understanding what a AS is supposed to do to delete 
a client still seems a touch vague to me.   I understand the http verb but 
there is more to it than that if we want interoperability.

John

On 2013-02-14, at 12:31 AM, Nat Sakimura  wrote:

> I thought your concern about DELETE was whether the client should be
> allowed to erase the registration data.
> I thought PUT with an empty values would achieve a similar effect.
> Or did you mean that with PUT, the server default kicks in and
> parameters are set to the defaults?
> If that is the case, they are quite different, I agree.
> 
> On the effect of DELETE, +1 to Tim's comment.
> 
> Nat
> 
> 2013/2/14 John Bradley :
>> DELETE is removing the record not resetting it to defaults.  They are quite 
>> diffrent.
>> 
>> I want to agree on what the expected behaviour of DELETE is.   I think we 
>> have agreement on PUT and POST.
>> 
>> The general not in that a client can DELETE it's record is a implication I 
>> don't like.  I think that is for the server to decide and if it is not 
>> actually deleting it then DELETE is the wrong verb to use.
>> 
>> John B.
>> 
>> On 2013-02-13, at 3:31 PM, Nat Sakimura  wrote:
>> 
>>> Generally speaking, mapping PUT to replace and POST to change is an
>>> acceptable practice so I am fine with it.
>>> 
>>> Now, what I still do not understand is why you think it is fine to do
>>> PUT or POST and not DELETE. Doing PUT with empty content is almost the
>>> same as DELETE. Could you explain?
>>> 
>>> =nat via iPhone
>>> 
>>> Feb 14, 2013 0:10、John Bradley  のメッセージ:
>>> 
 I am not violently opposed to PUT as a option that completely replaces the 
 resource setting all unsent claims back to the defaults.
 
 I don't have a good feeling about DELETE,  I think we still need more 
 discussion on what it means, what privileges it takes to invoke it etc.
 It could be a bad thing if we get wrong or is not implemented consistently.
 
 Personally I don't think a client should ever be able to DELETE it's 
 record.
 
 I think marking a client_id as pending provisioning, suspended,  revoked 
 etc is better and that can be done with a claim in the update endpoint.
 
 It should only be the server that deletes a record after satisfying it's 
 audit requirements.
 
 John B.
 
 On 2013-02-13, at 12:00 PM, Justin Richer  wrote:
 
> Would it be reasonable to mark the PUT and DELETE methods as optional for 
> the server to implement, but with defined semantics if they do? I want to 
> keep GET and POST(create) as mandatory, as I think that's the minimal set 
> of functionality required.
> 
> -- Justin
> 
> On 02/11/2013 08:51 PM, John Bradley wrote:
>> I would always include the client_id on update.
>> 
>> I think it is also us full to have other tokens used at the update 
>> endpoint.  I can see the master token used to update all the clients it 
>> has registered as part of API management.
>> Relying on the registration_access_token is probably a design that will 
>> cause trouble down the road.
>> 
>> I think GET and POST are relatively clear.   I don't know about 
>> expelling PUT to developers.  I think POST with a client_id to a 
>> (separate discussion) update_uri works without restricting it to PUT.
>> 
>> I think DELETE needs to be better understood.   I think a status that 
>> can be set for client lifecycle is better than letting a client delete a 
>> entry.
>> In some cases there will be more than one instance of a client and 
>> letting them know they have been turned off for a reason is better than 
>> making there registration disappear.
>> So for the moment I would levee out DELETE.
>> 
>> John B.
>> 
>> On 20

Re: [OAUTH-WG] Minutes from the OAuth Design Team Conference Call - 11th February 2013

[Justin Richer]

On 02/14/2013 02:45 AM, Hannes Tschofenig wrote:

Hi Prateek,


thanks for your questions.


On Feb 13, 2013, at 6:13 PM, Prateek Mishra wrote:


Hannes,

1) Its not clear to me that we need  to specify exchanges between the AS and 
the RS as part of this work. The core specification leaves this
unspecified. There could be many different ways that the AS and RS collaborate 
to validate signatures in messages received from the client.

It depends what the group wants to accomplish. So far, I thought that the goal 
was to offer the ability to provide a sufficient description in our 
specifications so that the authorization server and the resource server can be 
provided by different vendors and that they still interoperate.

The group may have changed their mind in the meanwhile.

What is your view?


My view on this, as expressed in the call, is that the interoperability 
be between the Client and AS and between the Client and RS. 
Interoperability between AS and RS from different vendors is a different 
question all together, and I don't think it really ought to be in scope 
for this. I think that with this signed token component we should build 
something that doesn't *preclude* this kind of AS/RS interop, but that 
the solution to that is a more general question. This is the motivation 
behind things like the token introspection draft.



2) Regarding (symmetric) key distribution, dont we need some kind of existing 
trust relationship between the client and AS to make this possible? I guess it
would be enough to require use of a "confidential" client, that would make it 
possible for the two parties to agree on a session key at the point where an access token
is  issued by the AS.

That's a very good question. I have not formed an option about this issue yet 
particularly given the recent capability to dynamically register clients.


I don't think that signing tokens should require confidential clients. 
This was one of the implementation issues with OAuth 1, as it required a 
"consumer_secret" at all times. This led to Google telling people to use 
"anonymous" as the "consumer_secret" for what were effectively public 
clients. Even with dynamic registration, there's still a place for 
public clients, in my opinion.



3) I think do need an MTI key distribution protocol as part of the 
specification, leaving that as a choice would hurt interoperability.

That's my impression as well.


I agree that we need to pick one style that assumes which party needs 
access to which keys and what time. I disagree that we need to define 
exactly how all of those keys get there.


 -- Justin


Ciao
Hannes


- prateek


Here are my notes.

Participants:

* John Bradley
* Derek Atkins
* Phil Hunt
* Prateek Mishra
* Hannes Tschofenig
* Mike Jones
* Antonio Sanso
* Justin Richer

Notes:

My slides are available here: 
http://www.tschofenig.priv.at/OAuth2-Security-11Feb2013.ppt

Slide #2 summarizes earlier discussions during the conference calls.

-- HTTP vs. JSON

Phil noted that he does not like to use the MAC Token draft as a starting point 
because it does not re-use any of the work done in the JOSE working group and 
in particular all the libraries that are available today. He mentioned that 
earlier attempts to write the MAC Token code lead to problems for implementers.

Justin responded that he does not agree with using JSON as a transport 
mechanism since this would replicate a SOAP style.

Phil noted that he wants to send JSON but the signature shall be computed over 
the HTTP header field.

-- Flexibility for the keyed message digest computation

 From earlier discussion it was clear that the conference call participants 
wanted more flexibility regarding the keyed message digest computation. For 
this purpose Hannes presented the DKIM based approach, which allows selective 
header fields to be included in the digest. This is shown in slide #4.

After some discussion the conference call participants thought that this would 
meet their needs. Further investigations would still be useful to determine the 
degree of failed HMAC calculations due to HTTP proxies modifying the content.

-- Key Distribution

Hannes presented the open issue regarding the choice of key distribution. 
Slides #6-#8 present three techniques and Hannes asked for feedback regarding 
the preferred style. Justin and others didn't see the need to decide on one 
mechanism - they wanted to keep the choice open. Derek indicated that this will 
not be an acceptable approach. Since the resource server and the authorization 
server may, in the OAuth 2.0 framework, be entities produced by different 
vendors there is an interoperability need. Justin responded that he disagrees 
and that the resource server needs to understand the access token and referred 
to the recent draft submission for the token introspection endpoint. Derek 
indicated that the resource server has to understand the content of the access 
token and the token introspection endpoint 

Re: [OAUTH-WG] Registration: RESTful client lifecycle management

[Justin Richer]

+1 to this. And I'd also be fine if it wasn't MTI (server returns a 405 
Method Not Allowed) for servers that don't want to do it at all.


 -- Justin


On 02/13/2013 04:26 PM, Tim Bray wrote:
A DELETE is an http request that asks the server to delete something. 
 We probably would want to avoid writing a requirement into the 
standard that the server has to comply.  So you get back a 204 if it 
worked, a 404 if there is no such registration, a 403 if there is but 
the server declines to delete, etc. Seems pretty straightforward. -T


On Wed, Feb 13, 2013 at 12:18 PM, John Bradley > wrote:


DELETE is removing the record not resetting it to defaults.  They
are quite diffrent.

I want to agree on what the expected behaviour of DELETE is. I
think we have agreement on PUT and POST.

The general not in that a client can DELETE it's record is a
implication I don't like.  I think that is for the server to
decide and if it is not actually deleting it then DELETE is the
wrong verb to use.

John B.

On 2013-02-13, at 3:31 PM, Nat Sakimura mailto:sakim...@gmail.com>> wrote:

> Generally speaking, mapping PUT to replace and POST to change is an
> acceptable practice so I am fine with it.
>
> Now, what I still do not understand is why you think it is fine
to do
> PUT or POST and not DELETE. Doing PUT with empty content is
almost the
> same as DELETE. Could you explain?
>
> =nat via iPhone
>
> Feb 14, 2013 0:10?John Bradley mailto:ve7...@ve7jtb.com>> ??:
>
>> I am not violently opposed to PUT as a option that completely
replaces the resource setting all unsent claims back to the defaults.
>>
>> I don't have a good feeling about DELETE,  I think we still
need more discussion on what it means, what privileges it takes to
invoke it etc.
>> It could be a bad thing if we get wrong or is not implemented
consistently.
>>
>> Personally I don't think a client should ever be able to DELETE
it's record.
>>
>> I think marking a client_id as pending provisioning, suspended,
 revoked etc is better and that can be done with a claim in the
update endpoint.
>>
>> It should only be the server that deletes a record after
satisfying it's audit requirements.
>>
>> John B.
>>
>> On 2013-02-13, at 12:00 PM, Justin Richer mailto:jric...@mitre.org>> wrote:
>>
>>> Would it be reasonable to mark the PUT and DELETE methods as
optional for the server to implement, but with defined semantics
if they do? I want to keep GET and POST(create) as mandatory, as I
think that's the minimal set of functionality required.
>>>
>>> -- Justin
>>>
>>> On 02/11/2013 08:51 PM, John Bradley wrote:
 I would always include the client_id on update.

 I think it is also us full to have other tokens used at the
update endpoint.  I can see the master token used to update all
the clients it has registered as part of API management.
 Relying on the registration_access_token is probably a design
that will cause trouble down the road.

 I think GET and POST are relatively clear.   I don't know
about expelling PUT to developers.  I think POST with a client_id
to a (separate discussion) update_uri works without restricting it
to PUT.

 I think DELETE needs to be better understood.   I think a
status that can be set for client lifecycle is better than letting
a client delete a entry.
 In some cases there will be more than one instance of a
client and letting them know they have been turned off for a
reason is better than making there registration disappear.
 So for the moment I would levee out DELETE.

 John B.

 On 2013-02-11, at 6:14 PM, Justin Richer mailto:jric...@mitre.org>> wrote:

> Draft -05 of OAuth Dynamic Client Registration [1] defines
several operations that the client can take on its behalf as part
of the registration process. These boil down to the basic CRUD
operations that you find in many APIs: Create, Read, Update,
Delete. Draft -00 defined only the "Create" operation, draft -01
through -04 added the "Update" operation, switched using the
"operation=" parameter.
>
> Following several suggestions to do so on the list, the -05
draft defines these operations in terms of a RESTful API for the
client. Namely:
>
> - HTTP POST to registration endpoint => Create (register) a
new client
> - HTTP PUT to update endpoint (with
registration_access_token) => Update the registered information
for this client
> - HTTP GET to update endpoint (with
registration_access_token) => read the registered information for
this client
> - HTTP DELETE to update endpoint (with

Re: [OAUTH-WG] Fwd: New Version Notification for draft-richer-oauth-introspection-02.txt

[Prabath Siriwardena]

I noticed that the latest Token Revocation draft [1] has introduced the
parameter "token_type_hint". I would suggest the same here, as that would
make what is meant by "valid" much clear..

[1]: http://tools.ietf.org/html/draft-ietf-oauth-revocation-05

Thanks & regards,
-Prabath

On Tue, Feb 12, 2013 at 9:35 PM, Prabath Siriwardena wrote:

> Hi Justin,
>
> I doubt whether valid_token would make a difference..?
>
> My initial argument is what is the validation criteria..? Validation
> criteria depends on the token_type..
>
> If we are talking only about metadata - then I believe "revoked",
> "expired" would be more meaningful..
>
> Thanks & regards,
> -Prabath
>
>
> On Tue, Feb 12, 2013 at 7:53 PM, Justin Richer  wrote:
>
>>  OK, I can see the wisdom in changing this term.
>>
>> I picked "valid" because I wanted a simple "boolean" value that would
>> require no additional parsing or string-matching on the client's behalf,
>> and I'd like to stick with that. OAuth is built with the assumption that
>> clients need to be able to recover from invalid tokens at any stage, so I
>> think a simple yes/no is the right step here.
>>
>> That said, I think you're both right that "valid" seems to have caused a
>> bit of confusion. I don't want to go with "revoked" because I'd rather have
>> the "token is OK" be the positive boolean value.
>>
>> Would "valid_token" be more clear? Or do we need a different adjective
>> all together?
>>
>>  -- Justin
>>
>>
>> On 02/11/2013 08:02 PM, Richard Harrington wrote:
>>
>> Have you considered "status" instead of "valid"?  It could have values
>> like "active", "expired", and "revoked".
>>
>>  Is it worthwhile including the status of the client also?  For example,
>> a client application could be disabled, temporarily or permanently, and
>> thus disabling its access tokens as well.
>>
>>
>> On Feb 11, 2013, at 1:56 PM, Prabath Siriwardena 
>> wrote:
>>
>>  I guess confusion is with 'valid' parameter is in the response..
>>
>>  I thought this will be helpful to standardize the communication between
>> Resource Server and the Authorization Server..
>>
>>  I would suggest we completely remove "valid" from the response - or
>> define it much clearly..
>>
>>  May be can add "revoked" with a boolean attribute..
>>
>>  Thanks & regards,
>> -Prabath
>>
>> On Tue, Feb 12, 2013 at 3:19 AM, Justin Richer  wrote:
>>
>>>
>>> On 02/08/2013 12:51 AM, Prabath Siriwardena wrote:
>>>
>>> Hi Justin,
>>>
>>>  I have couple of questions related to "valid" parameter...
>>>
>>>  This endpoint can be invoked by the Resource Server in runtime...
>>>
>>>
>>> That's correct.
>>>
>>>
>>>
>>>  In that case what is exactly meant by the "resource_id" in request ?
>>>
>>>
>>>  The resource_id field is a service-specific string that basically lets
>>> the resource server provide some context to the request to the auth server.
>>> There have been some other suggestions like client IP address, but I wanted
>>> to put this one in because it seemed to be a common theme. The client is
>>> trying to do *something* with the token, after all, and the rights,
>>> permissions, and metadata associated with the token could change based on
>>> that. Since the Introspection endpoint is all about getting that metadata
>>> back to the PR, this seemed like a good idea.
>>>
>>>
>>>
>>>  IMO a token to be valid depends on set of criteria based on it's type..
>>>
>>>  For a Bearer token..
>>>
>>>  1. Token should not be expired
>>> 2. Token should not be revoked.
>>> 3. The scope the token issued should match with the scope required for
>>> the resource.
>>>
>>>  For a MAC token...
>>>
>>>  1. Token not expired (mac id)
>>> 2. Token should not be revoked
>>> 3. The scope the token issued should match with the scope required for
>>> the resource.
>>> 4. HMAC check should be valid
>>>
>>>  There are similar conditions for SAML bearer too..
>>>
>>>
>>>  This isn't really true. The SAML bearer token is fully self-contained
>>> and doesn't change based on other parameters in the message, unlike MAC.
>>> Same with JWT. When it hands a SAML or JWT token to the AS, the PR has
>>> given *everything* the server needs to check that token's validity and use.
>>>
>>> MAC signatures change with every message, and they're done across
>>> several components of the HTTP message. Therefor, the HMAC check for MAC
>>> style tokens will still need to be done by the protected resource.
>>> Introspection would help in the case that the signature validated just
>>> fine, but the token might have expired. Or you need to know what scopes
>>> apply. Introspection isn't to fully validate the call to the protected
>>> resource -- if that were the case, the PR would have to send some kind of
>>> encapsulated version of the original request. Otherwise, the AS won't have
>>> all of the information it needs to check the MAC.
>>>
>>>
>>> I think what you're describing is ultimately *not* what the
>>> introspection endpoint is intended to do. If that's unclear from th

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-revocation-05.txt

[Sergey Beryozkin]

Hi
On 13/02/13 22:19, Torsten Lodderstedt wrote:

Hi all,

I just published a new revision, which should cover all the issues
raised/dicussed during WGLC.

I applied the following changes:
- introduced a new parameter "token_type_hint", which a client may use
to give the authorization server a hint about the type of the token to
be revoked
- replaced "authorization" by "authorization grant"
- an attempt to revoke an invalid token is now handled like a successful
revocation request (status code 200)
Does it create some precedent, meaning that while people suggest using 
4xx statuses to indicate different sort of failures in this case 200 is 
returned, to eliminate a potential security attack. I mean, should it 
become the recommended practice ?


For example, in the discussion about DELETE, should it be 204 that is 
returned all the time ?


Sergey

- CORS is now a MAY instead of SHOULD
- extended description of how developer/client may obtain endpoint location
- Improved wording regarding expected client behavior after sucessful
processing of the revocation request -> "The client must assume the
revocation is immediate upon the return of the request."
- Explanation of different policies and why having different server
policies should not cause interop problems
- aligned structure with core spec by introducing sub-sections for
request and response

regards,
Torsten.

Am 13.02.2013 23:13, schrieb internet-dra...@ietf.org:

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

Title : Token Revocation
Author(s) : Torsten Lodderstedt
Stefanie Dronia
Marius Scurtescu
Filename : draft-ietf-oauth-revocation-05.txt
Pages : 9
Date : 2013-02-13

Abstract:
This document proposes an additional endpoint for OAuth authorization
servers, which allows clients to notify the authorization server that
a previously obtained refresh or access token is no longer needed.
This allows the authorization server to cleanup security credentials.
A revocation request will invalidate the actual token and, if
applicable, other tokens based on the same authorization grant.



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

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-oauth-revocation-05

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-revocation-05


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

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


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



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