Subject: [OAUTH-WG] WGLC on draft-ietf-oauth-saml2-bearer-03.txt

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 19 Mar 2011 19:58:13 +0200

Hi all, 

the WGLC for the OAuth base specification has been completed and the authors think that this document is ready for a WGLC as well. 

Hence, let us start the last call for comments on http://www.ietf.org/id/draft-ietf-oauth-saml2-bearer-03.txt

Please have your comments in no later than April 2nd.

Do remember to send a note in if you have read the document and have no other comments other than "its ready to go". 

Thanks!
Hannes & Blaine

---

From: Mike Jones <[email-masked]>
Date: Sat, 19 Mar 2011 18:03:46 +0000

I'm confused.  Per the attached message that you sent on March 1st, the last call period started then and ended on March 16th.  How is this second last call different?

				Thanks,
				-- Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Hannes Tschofenig
Sent: Saturday, March 19, 2011 10:58 AM
To: [email-masked] WG
Subject: [OAUTH-WG] WGLC on draft-ietf-oauth-saml2-bearer-03.txt

Hi all, 

Thanks!
Hannes & Blaine
_______________________________________________
OAuth mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/oauth

Subject: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-13.txt
From: Hannes Tschofenig <[email-masked]>
To: OAuth WG <[email-masked]>
Date: Wed, 2 Mar 2011 07:32:05 +0000
List-Id: OAUTH WG <oauth.ietf.org>

This is a Last Call for comments on

http://www.ietf.org/id/draft-ietf-oauth-v2-13.txt

Please have your comments in no later than March 16.

Do remember to send a note in if you have read the document and have no
other comments other than "its ready to go" - we need those as much as we need "I found a problem".

Thanks!
Hannes & Blaine

_______________________________________________
OAuth mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/oauth

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Sat, 19 Mar 2011 11:37:53 -0700

We had last calls for v2 and bearer. This is for the SAML profile.

EHL

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Mike Jones
> Sent: Saturday, March 19, 2011 11:04 AM
> To: Hannes Tschofenig; [email-masked] WG
> Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-saml2-bearer-03.txt
> 
> I'm confused.  Per the attached message that you sent on March 1st, the last
> call period started then and ended on March 16th.  How is this second last call
> different?
> 
> 				Thanks,
> 				-- Mike
> 
> the WGLC for the OAuth base specification has been completed and the
> authors think that this document is ready for a WGLC as well.
> 
> Hence, let us start the last call for comments on
> http://www.ietf.org/id/draft-ietf-oauth-saml2-bearer-03.txt
> 
> other comments other than "its ready to go".
> 
> Thanks!
> Hannes & Blaine

---

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 19 Mar 2011 21:50:29 +0200

Correct. 

WGLC on draft-ietf-oauth-v2-13.txt is finished. 
WGLC on draft-ietf-oauth-v2-bearer-03.txt is still ongoing till March 25.
WGLC on draft-ietf-oauth-saml2-bearer-03.txt got just started.

On Mar 19, 2011, at 8:37 PM, Eran Hammer-Lahav wrote:

>> Of Hannes Tschofenig

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 23 Mar 2011 11:05:02 -0600

<hat type='AD'/>

On 3/19/11 11:58 AM, Hannes Tschofenig wrote:
> Do remember to send a note in if you have read the document and have
> no other comments other than "its ready to go".
> 
> Thanks! Hannes & Blaine 

I've completed a review of this spec, the bearer token spec, and the
base spec. This is the first WGLC message I found in my inbox, so I'm
posting about this spec first. :)

Overall I think this short spec is in fine shape. I have a few small
comments.

1. The grant type is a URI at oauth.net. Is that a stable URI? Does it
need to be?

We could define a new URN parameters registry for grant types that are
defined in standards-track RFCs:

http://www.iana.org/assignments/params/params.xml

However, that might be perceived as overkill.

2. Both the SAML-bearer and v2-bearer specs borrow text from the base
spec when a reference seems better. For example, in Section 2.1 of the
SAML-bearer spec we find this:

   scope
         OPTIONAL.  The scope of the access request is expressed as a
         list of space-delimited strings.  The value is defined by the
         authorization server.  If the value contains multiple space-
         delimited strings, their order does not matter, and each string
         adds an additional access range to the requested scope.

However, that's already defined in Section 4.1.1 of the base spec:

   scope
         OPTIONAL.  The scope of the access request expressed as a list
         of space-delimited strings.  The value is defined by the
         authorization server.  If the value contains multiple space-
         delimited strings, their order does not matter, and each string
         adds an additional access range to the requested scope.

I think it would be better to reference the definitions in the base spec
so that they don't get out of sync.

3. Regarding "invalid_grant" in Section 2.3, I'll post in the thread
about a possible registry of error parameter values.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Brian Campbell <[email-masked]>
Date: Wed, 23 Mar 2011 15:38:57 -0600

Thank for the review and comment, Peter, some replies and new
questions are inline below.

> 1. The grant type is a URI at oauth.net. Is that a stable URI? Does it

I honestly don't know the answer to either question.  I certainly
don't own the domain.  I needed *some* URI to identify the grant type
and, for lack of knowing any better, just used http://oauth.net as it
seemed semi-appropriate and threw on a path that sort of described
what it was.  I think I might even asked you about it early on in this
process and gotten a "it's fine for now" type of response :)  Perhaps
that now is over and it needs to be something else?

> However, that might be perceived as overkill.

That does seem a bit overkill but I don't know.  Is there some middle ground?

> so that they don't get out of sync.

Up though -12 of the base spec, this spec did use that definition of
the scope parameter from the base spec.  In those earlier versions,
all the base parameters for the token endpoint were defined in one
place and it was very natural to 'inherit' scope from it.  The way the
base spec was reorganized in -13 made that inheritance awkward because
each individual type of request redefines all the parameters.  In
fact, in the base spec, that exact text is repeated in three or four
places and slight variations of it show up in several other paces.
Generally, I think the re-org made it more readable but it also
resulted in more such duplication.

Anyway, I digress. Is it reasonable/possible to reference the
definition in the base spec when the definition is the same but the
context of use is a little off? Can you suggest some text? Or point me
to an I-D/RFC that has done something similar?

> about a possible registry of error parameter values.

I'm trying to stay out of the debate regarding additional registries:)
 But I will say that, from the perspective of this specification, I
think that the top level "invalid_grant" error code with optionally
more descriptive content in the error_description parameter is
probably sufficient.