Re: [OAUTH-WG] URI for OAuth SAML assertion grant type

Hannes Tschofenig <> Sat, 09 July 2011 16:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CF5A321F8677 for <>; Sat, 9 Jul 2011 09:40:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.583
X-Spam-Status: No, score=-102.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id YO4K+vk2uxZE for <>; Sat, 9 Jul 2011 09:40:41 -0700 (PDT)
Received: from ( []) by (Postfix) with SMTP id D0F7621F86BF for <>; Sat, 9 Jul 2011 09:40:40 -0700 (PDT)
Received: (qmail invoked by alias); 09 Jul 2011 16:40:38 -0000
Received: from (EHLO []) [] by (mp037) with SMTP; 09 Jul 2011 18:40:38 +0200
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX18avVFnnUIalc/2aQfUF+E/um4qNTswoZ7ViNqgK1 IQSEBpKdxqfxGP
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="us-ascii"
From: Hannes Tschofenig <>
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234501D4A0143@P3PW5EX1MB01.EX1.SECURESERVER.NET>
Date: Sat, 09 Jul 2011 19:40:36 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <90C41DD21FB7C64BB94121FBBC2E7234501D4A0143@P3PW5EX1MB01.EX1.SECURESERVER.NET>
To: Eran Hammer-Lahav <>
X-Mailer: Apple Mail (2.1084)
X-Y-GMX-Trusted: 0
Cc: OAuth WG <>, "" <>
Subject: Re: [OAUTH-WG] URI for OAuth SAML assertion grant type
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 09 Jul 2011 16:40:41 -0000

Hi Eran, 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


   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:

      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.

      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


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

> 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
> Is there a BCP established for this? We need to pick a value quickly and move on.
> [1]
> [2]
> [3]
> _______________________________________________
> OAuth mailing list