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

[Brian Campbell <[e-mail]>]

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 <[e-mail]> 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.