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 protected] [mailto:[email protected]] 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)]
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 protected]> 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.
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
