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

Brian Campbell <bcampbell@pingidentity.com> Sat, 09 July 2011 19:28 UTC

Return-Path: <bcampbell@pingidentity.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D462E21F89BC; Sat, 9 Jul 2011 12:28:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.941
X-Spam-Level:
X-Spam-Status: No, score=-5.941 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UwfTwQiCbyv2; Sat, 9 Jul 2011 12:28:37 -0700 (PDT)
Received: from na3sys009aog115.obsmtp.com (na3sys009aog115.obsmtp.com [74.125.149.238]) by ietfa.amsl.com (Postfix) with ESMTP id 6BFF421F899D; Sat, 9 Jul 2011 12:28:37 -0700 (PDT)
Received: from mail-qy0-f180.google.com ([209.85.216.180]) (using TLSv1) by na3sys009aob115.postini.com ([74.125.148.12]) with SMTP ID DSNKThir5AEPuZTpXMzU+Ezv6gP48tXhWs5V@postini.com; Sat, 09 Jul 2011 12:28:37 PDT
Received: by mail-qy0-f180.google.com with SMTP id 30so2374839qyk.18 for <multiple recipients>; Sat, 09 Jul 2011 12:28:36 -0700 (PDT)
Received: by 10.224.198.201 with SMTP id ep9mr2414806qab.126.1310239716231; Sat, 09 Jul 2011 12:28:36 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.224.28.201 with HTTP; Sat, 9 Jul 2011 12:28:06 -0700 (PDT)
In-Reply-To: <E0447DFD-D209-417E-A21B-D636CEC0F190@gmx.net>
References: <90C41DD21FB7C64BB94121FBBC2E7234501D4A0143@P3PW5EX1MB01.EX1.SECURESERVER.NET> <E0447DFD-D209-417E-A21B-D636CEC0F190@gmx.net>
From: Brian Campbell <bcampbell@pingidentity.com>
Date: Sat, 09 Jul 2011 13:28:06 -0600
Message-ID: <CA+k3eCTjG5HoDTdB=PVrU-1FpkWqWTLpMM_zAFP-x9_XGXU_3Q@mail.gmail.com>
To: Hannes Tschofenig <hannes.tschofenig@gmx.net>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Sun, 10 Jul 2011 13:07:48 -0700
Cc: "apps-discuss@ietf.org" <apps-discuss@ietf.org>, OAuth WG <oauth@ietf.org>
Subject: Re: [apps-discuss] [OAUTH-WG] URI for OAuth SAML assertion grant type
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 09 Jul 2011 19:28:39 -0000

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.

On Sat, Jul 9, 2011 at 10:40 AM, Hannes Tschofenig
<hannes.tschofenig@gmx.net> wrote:
> 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:
>
>> 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
>>
>> _______________________________________________
>> 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
>