Subject: [apps-discuss] URI for OAuth SAML assertion grant type

From: Eran Hammer-Lahav <[email-masked]>
Date: Sat, 9 Jul 2011 08:17:20 -0700

The OAuth WG is looking for assistance from the application area community.

OAuth 2.0 [1] defines a URI-namespaced method for defining extension grant types[2]. The first specification to use this method needs to pick a URI identifier for using SAML assertions [3]. Options proposed:

urn:oasis:names:tc:SAML:2.0:assertion
urn:ietf:wg:oauth:2.0:grant_type:saml:2.0:bearer
http://oauth.net/grant_type/saml/2.0/bearer

Is there a BCP established for this? We need to pick a value quickly and move on.

EHL

[1] http://tools.ietf.org/html/draft-ietf-oauth-v2-18
[2] http://tools.ietf.org/html/draft-ietf-oauth-v2-18#section-8.3
[3] http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-04

---

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 9 Jul 2011 19:40:36 +0300

Hi Eran, 

http://oauth.net/grant_type/saml/2.0/bearer is definitely not a good idea since a lookup would not return anything useful (most likely it will just fail). 
Whenever there is something that can be looked up, it will be looked up . 

I would create an IETF URN Sub-namespace, as documented in RFC 3553. An example of such a sub-namespace is xml and described in RFC 3688. 
So, one could define a new 'oauth' sub-namespace. This would then look like urn:ietf:params:oauth. Then, OAuth relevant parameters would be established underneath it. 

To get this done three things are needed: 

1) Text that requests the oauth sub-namespace text
This text has to go into draft-ietf-oauth-v2.

2) Text that defines how values are added to this new registry
This text has to go into draft-ietf-oauth-v2.

3) Text that registers already defined values. 
This text would go into draft-ietf-oauth-saml2-bearer following the template created with (2). 

Regarding (1), example text could look like:

---------

IETF URN Sub-namespace Registration urn:ietf:params:oauth

   Per [RFC3553], IANA is requested to establish the following registry.  New entries
   to the registry are Specification Required.

   Registry name: urn:ietf:params:oauth

   Specification:  Section X of this document contains the registry specification.

   Repository: To be assigned according to the guidelines found above.

   Index value: The class name

---------

Regarding (2), example text could look like: 
 
---------

Section X: Registration Template for Sub-Namspace Registration of urn:ietf:params:oauth    

   If the registrant wishes to
   have a URI assigned, then a URN of the form

      urn:ietf:params:oauth:<class>:<id>

   will be assigned where <class> is the category of the parameters being registered.  <id> is a unique id generated by the IANA
   based on any means the IANA deems necessary to maintain uniqueness
   and persistence.  NOTE: in order for a URN of this type to be
   assigned, the item being registered MUST be documented
   in a RFC.  The RFC 3553 [RFC3553] URN registration template is found
   in the IANA consideration section of this document.
   
   The registration procedure for new entries to the requires a request in the form of the following template:

   URN:
      The token URI that identifies the registerd component. If
      the registrant is requesting that the IANA assign a URI then this
      field should be specified as "please assign".
 
   Common Name: 
      The name by which the functionality being registered is generally referred.
      
   Registrant Contact:
      The individual/organization that is the registration contact for
      the component being registered.  Ideally, this will be the name
      and pertinent physical and network contact information.  In the
      case of IETF developed standards, the Registrant will be the IESG.

   Description:
      Information about the registered functionality.  

---------

Regarding (3), example text could look like: 
 
---------

Sub-Namspace Registration of urn:ietf:params:oauth:grant-type:saml2-bearer

This is a request to IANA to please register the value grant-type:saml2-bearer in the registry urn:ietf:params:oauth established in [draft-ietf-oauth-v2]. 

   URN: urn:ietf:params:oauth:grant-type:saml2-bearer

   Common Name: SAML 2.0 Bearer Assertion Grant Type Profile for OAuth 2.0
      
   Registrant Contact: IESG
   
   Description: [[this document]]
   
---------

Other grant types would then go in urn:ietf:params:oauth:grant-type:saml2-holder-of-the-key
Other OAuth related parameters then go under urn:ietf:params:oauth:foobar

Ciao
Hannes

On Jul 9, 2011, at 6:17 PM, Eran Hammer-Lahav wrote:

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

---

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 9 Jul 2011 20:04:09 +0300

> Other grant types would then go in urn:ietf:params:oauth:grant-type:saml2-holder-of-the-key

This sentence from my earlier mail could be misunderstood. To pick Mike's example for the JWT assertion profile we would then register something like: 
urn:ietf:params:oauth:grant-type:jwt1.0-bearer

---

From: Brian Campbell <[email-masked]>
Date: Sat, 9 Jul 2011 13:28:06 -0600

Thank you for taking the initiate to post this, Eran.  And thank you,
Hannes, for the detailed and actionable reply.

If Eran is willing/able to do #1 & #2, I'd be more than happy to do #3.