Subject: Re: [OAUTH-WG] SAML Assertion Draft Items [Item 2: URI(s)]

From: Brian Campbell <[email-masked]>
Date: Sat, 9 Jul 2011 07:14:59 -0600

Discussion on the other item, the grant_type URI, inline below.

This whole thing seems like it shouldn't be an issue at all as there's
no functionality involved.  But I've been hung up on it for a while
and the spec needs some URI. I could *really* use the advice of the AD
and/or Chairs on this.  Or anyone with more experience with defining
and using URIs/URNs.

Thanks.

On Thu, Jul 7, 2011 at 11:24 PM, Eran Hammer-Lahav <[email-masked]> wrote:
>
>> Item 2: URI(s)
>> The value for grant_type is currently defined as
>> http://oauth.net/grant_type/saml/2.0/bearer but there have been some
>> questions raised about the stability and appropriateness of the URL.
>
> I'm not a fan.
>
>> I really did read RFCs 2648 & 3553, as was suggested at the last F2F meeting,
>> but it's not clear to me how to register an IETF URI and/or if those RFCs are
>> fully appropriate for this.  If someone could explain it to me in terms my
>> preschooler could understand, maybe I could jump though the proper hoops
>> to get the URI to be something like urn:ietf:something:something.
>
> Asking on the URN list usually helps.

I can try that.

I'm thinking it'd be something like
urn:ietf:wg:oauth:2.0:grant_type:saml:2.0:bearer which is largely
based on seeing the use of urn:ietf:wg:oauth:2.0:oob - was there an
actual registration done for that?  Or did it just start getting used?
Is doing that okay?

>
>> Otherwise, I can continue to use
>> http://oauth.net/grant_type/saml/2.0/bearer and, assuming the draft
>> should also cover client authentication, also define
>> http://oauth.net/client_assertion_type/saml/2.0/bearer.  The JWT version
>> could then follow a similar pattern.  Or perhaps we could use the URI,
>> urn:oasis:names:tc:SAML:2.0:cm:bearer which is defined in section 3.3 of
>> saml-profiles-2.0-os as URI that identifies the bearer subject confirmation
>> method.  It seems like that might be close enough to work out without
>> violating anything serious.  And it could be used for both grant_type and
>> client_assertion_type, which is nice.
>
> Don't use an OASIS URN. That's asking for trouble.

Is it really?  Because it's conceptually inappropriate?  Or because of
some supposed (or real) rift between standards bodies?  I mean, this
whole draft is about profiling SAML assertions (an OASIS spec) for use
with OAuth (soon an IETF spec).  Would using a URN too be so terrible?

You'd previously suggested (or asked why I didn't use)
urn:oasis:names:tc:SAML:2.0:assertion which is the XML NS for the
OASIS SAML assertion schema.  Would that somehow be different?  That
is still an option too, I think.  I hadn't used it because I wanted to
differentiate the means of confirming/validating the assertion - as a
bearer token - while leavening room for holder of key or other methods
in the future.  But using that NS wouldn't necessary preclude it.  I
was also looking for an identifier that would enable easy web
searching and urn:oasis:names:tc:SAML:2.0:assertion wouldn't really do
that.

---

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

> -----Original Message-----
> From: Brian Campbell [mailto:[email-masked]]
> Sent: Saturday, July 09, 2011 6:15 AM
> To: Eran Hammer-Lahav
> Cc: oauth
> Subject: Re: [OAUTH-WG] SAML Assertion Draft Items [Item 2: URI(s)]
> 
> This whole thing seems like it shouldn't be an issue at all as there's no
> functionality involved.  But I've been hung up on it for a while and the spec
> needs some URI. I could *really* use the advice of the AD and/or Chairs on
> this.  Or anyone with more experience with defining and using URIs/URNs.
> 
> Thanks.
> 
> >> I really did read RFCs 2648 & 3553, as was suggested at the last F2F
> >> meeting, but it's not clear to me how to register an IETF URI and/or
> >> if those RFCs are fully appropriate for this.  If someone could
> >> explain it to me in terms my preschooler could understand, maybe I
> >> could jump though the proper hoops to get the URI to be something like
> urn:ietf:something:something.
> >
> urn:ietf:wg:oauth:2.0:grant_type:saml:2.0:bearer which is largely based on
> seeing the use of urn:ietf:wg:oauth:2.0:oob - was there an actual registration
> done for that?  Or did it just start getting used?
> Is doing that okay?

2648 is pretty limited in what it offers for the urn:ietf namespace. I'll post something to the app area list.

> >> http://oauth.net/client_assertion_type/saml/2.0/bearer.  The JWT
> >> version could then follow a similar pattern.  Or perhaps we could use
> >> the URI, urn:oasis:names:tc:SAML:2.0:cm:bearer which is defined in
> >> section 3.3 of saml-profiles-2.0-os as URI that identifies the bearer
> >> subject confirmation method.  It seems like that might be close
> >> enough to work out without violating anything serious.  And it could
> >> be used for both grant_type and client_assertion_type, which is nice.
> >
> Is it really?  Because it's conceptually inappropriate?  Or because of some
> supposed (or real) rift between standards bodies?  I mean, this whole draft is
> about profiling SAML assertions (an OASIS spec) for use with OAuth (soon an
> IETF spec).  Would using a URN too be so terrible?
> 
> urn:oasis:names:tc:SAML:2.0:assertion which is the XML NS for the OASIS
> SAML assertion schema.  Would that somehow be different?  That is still an
> option too, I think.  I hadn't used it because I wanted to differentiate the
> means of confirming/validating the assertion - as a bearer token - while
> leavening room for holder of key or other methods in the future.  But using
> that NS wouldn't necessary preclude it.  I was also looking for an identifier
> that would enable easy web searching and
> urn:oasis:names:tc:SAML:2.0:assertion wouldn't really do that.

My experience is that people at the IETF have an allergic reaction to OASIS and while SAML is well-established, I would be surprised if you get far with using an OASIS namespace. Also, OASIS should be the only entity controlling the use of their identifiers and in theory, might want to use it with OAuth in a different way.

EHL

---

From: Mike Jones <[email-masked]>
Date: Sat, 9 Jul 2011 16:25:09 +0000

If you're going with urn:ietf:wg:oauth:2.0:grant_type:saml:2.0:bearer in the SAML assertion profile, I'll use urn:ietf:wg:oauth:2.0:grant_type:jwt:1.0:bearer in the JWT assertion profile.

				-- Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Brian Campbell
Sent: Saturday, July 09, 2011 6:15 AM
To: Eran Hammer-Lahav
Cc: oauth
Subject: Re: [OAUTH-WG] SAML Assertion Draft Items [Item 2: URI(s)]

This whole thing seems like it shouldn't be an issue at all as there's no functionality involved.  But I've been hung up on it for a while and the spec needs some URI. I could *really* use the advice of the AD and/or Chairs on this.  Or anyone with more experience with defining and using URIs/URNs.

Thanks.

On Thu, Jul 7, 2011 at 11:24 PM, Eran Hammer-Lahav <[email-masked]> wrote:
>> could jump though the proper hoops to get the URI to be something like urn:ietf:something:something.
>

I can try that.

I'm thinking it'd be something like
urn:ietf:wg:oauth:2.0:grant_type:saml:2.0:bearer which is largely based on seeing the use of urn:ietf:wg:oauth:2.0:oob - was there an actual registration done for that?  Or did it just start getting used?
Is doing that okay?

> Don't use an OASIS URN. That's asking for trouble.

Is it really?  Because it's conceptually inappropriate?  Or because of some supposed (or real) rift between standards bodies?  I mean, this whole draft is about profiling SAML assertions (an OASIS spec) for use with OAuth (soon an IETF spec).  Would using a URN too be so terrible?

You'd previously suggested (or asked why I didn't use) urn:oasis:names:tc:SAML:2.0:assertion which is the XML NS for the OASIS SAML assertion schema.  Would that somehow be different?  That is still an option too, I think.  I hadn't used it because I wanted to differentiate the means of confirming/validating the assertion - as a bearer token - while leavening room for holder of key or other methods in the future.  But using that NS wouldn't necessary preclude it.  I was also looking for an identifier that would enable easy web searching and urn:oasis:names:tc:SAML:2.0:assertion wouldn't really do that.
_______________________________________________
OAuth mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/oauth