Re: [OAUTH-WG] URI for OAuth SAML assertion grant type
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
Re: [OAUTH-WG] URI for OAuth SAML assertion grant type
On Jul 9, 2011, at 7:40 PM, Hannes Tschofenig wrote: 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 ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] URI for OAuth SAML assertion grant type
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.tschofe...@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
Re: [OAUTH-WG] URI for OAuth SAML assertion grant type
(- apps-discuss) I don't have the bandwidth to do anything other than edit the v2 document. Sorry. EHL -Original Message- From: Brian Campbell [mailto:bcampb...@pingidentity.com] Sent: Saturday, July 09, 2011 12:28 PM To: Hannes Tschofenig Cc: Eran Hammer-Lahav; OAuth WG; apps-disc...@ietf.org Subject: Re: [OAUTH-WG] URI for OAuth SAML assertion grant type 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.tschofe...@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
