Subject: [OAUTH-WG] SAML Assertion Flow (was: Draft progress update)

From: Marius Scurtescu <[email-masked]>
Date: Thu, 1 Apr 2010 11:21:08 -0700

Instead of "SAML Assertion Flow" maybe we should stick with the more
generic "Assertion Flow".

The assertion_format parameter allows you to define the assertion
type. Maybe we can predefine
some well know formats, for example: "saml1", "saml1.1" and "saml2"?

Marius

On Wed, Mar 31, 2010 at 6:22 PM, Eran Hammer-Lahav <[email-masked]> wrote:
> I'm making good progress working off David's draft and bringing text from
> WRAP into it, as well as from OAuth 1.0a, and my token auth proposal. So far
> it is largely in line with David's proposal and the majority of changes are
> purely editorial.
>
> The only significant change I have made (which is of course open to debate)
> is renaming all the authorization flows parameters. I dropped the oauth_
> prefix (no real need since these are purely OAuth endpoints, not protected
> resources), and made most of the parameter names shorter. I am not done so
> they are not consistent yet.
>
> You can follow my progress (changes every few hours) at:
>
> http://github.com/theRazorBlade/draft-ietf-oauth/raw/master/draft-ietf-oauth
> .txt
>
> Please feel free to comment on anything you like or dislike. I will publish
> the whole thing as an I-D once it is feature complete for the WG to discuss
> before we promote this to a WG draft.
>
> I hope to be done with the initial draft by middle of next week (I'll be
> flying most of Fri-Sat so no progress over the weekend).
>
> EHL
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 1 Apr 2010 12:24:39 -0700

A generic assertion flow is too under-specified to be included. If a SAML2 assertion flow isn't enough or useful, we should define what is and fully specify it. The current text is still incomplete as it doesn't address how the assertion should be encoded in the request.

EHL

On 4/1/10 11:21 AM, "Marius Scurtescu" <[email-masked]> wrote:

Marius

---

From: Marius Scurtescu <[email-masked]>
Date: Thu, 1 Apr 2010 12:59:11 -0700

On Thu, Apr 1, 2010 at 12:24 PM, Eran Hammer-Lahav <[email-masked]> wrote:
> A generic assertion flow is too under-specified to be included.

Can you please give some more details, why is that?

For any assertion flow to work the client and the authorization server
must trust
each other, leaving the assertion format details up to them seems reasonable
to me.

Marius

---

From: Chuck Mortimore <[email-masked]>
Date: Thu, 1 Apr 2010 13:34:14 -0700

As you've pointed out, the current text is in somewhat of a grey area.   It's either over specified ( remove any reference to SAML ) or underspecified ( be very explicit about exactly what is expected )

I'd advocate that the core spec is left under-specified.   If we're prescriptive on the exact version and format of SAML, than the result will be other use-cases will simply force non-standard extensions.   It seems we do need to document exactly what what specific values of assertion_format requires, but the core spec should be open to multiple formats.

This would allow for flexibility with SAML, which has multiple versions, formats, and confirmation methods, but also allow for this message exchange patterns with completely different assertion types.   It will somewhat future proof the core spec.

Note that I'd be happy to work on the documentation of a specific format and contribute that to the group.

-cmort

On 4/1/10 12:24 PM, "Eran Hammer-Lahav" <[email-masked]> wrote:

EHL

Marius

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 1 Apr 2010 15:16:28 -0700

What is the value of an under specified flow? Especially one as short and simple as this one?

My point is that if the flow requires further profiling to be useful, the whole thing does belong in the core spec. It is short enough to be cut and paste into another spec repeatedly for each well specified assertion flow.

EHL

On Apr 1, 2010, at 16:34, "Chuck Mortimore" <[email-masked]<mailto:[email-masked]>> wrote:

As you’ve pointed out, the current text is in somewhat of a grey area.   It’s either over specified ( remove any reference to SAML ) or underspecified ( be very explicit about exactly what is expected )

I’d advocate that the core spec is left under-specified.   If we’re prescriptive on the exact version and format of SAML, than the result will be other use-cases will simply force non-standard extensions.   It seems we do need to document exactly what what specific values of assertion_format requires, but the core spec should be open to multiple formats.

Note that I’d be happy to work on the documentation of a specific format and contribute that to the group.

-cmort

On 4/1/10 12:24 PM, "Eran Hammer-Lahav" <<[email-masked]>[email-masked]<mailto:[email-masked]>> wrote:

A generic assertion flow is too under-specified to be included. If a SAML2 assertion flow isn’t enough or useful, we should define what is and fully specify it. The current text is still incomplete as it doesn’t address how the assertion should be encoded in the request.

EHL

On 4/1/10 11:21 AM, "Marius Scurtescu" <<[email-masked]>[email-masked]<mailto:[email-masked]>> wrote:

Marius

On Wed, Mar 31, 2010 at 6:22 PM, Eran Hammer-Lahav <<[email-masked]>[email-masked]<mailto:[email-masked]>> wrote:
> <http://github.com/theRazorBlade/draft-ietf-oauth/raw/master/draft-ietf-oauth> http://github.com/theRazorBlade/draft-ietf-oauth/raw/master/draft-ietf-oauth
> .txt
>
> <[email-masked]> [email-masked]<mailto:[email-masked]>
> <https://www.ietf.org/mailman/listinfo/oauth> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: Chuck Mortimore <[email-masked]>
Date: Thu, 1 Apr 2010 15:38:14 -0700

Flexibility.   If we lock Oauth2 down to one specific specific Assertion, it becomes unusable for other assertion formats.   Those assertion formats will evolve anyways.    Looked at somewhat differently, if there is only 1 assertion format supported by the spec, then what is the point of the assertion_format attribute?

So I'm clear, I'm 100% in favor of having a canonical assertion format for SAML with OAuth2, I really only intend to initially support 1 format, and I'm happy to take a stab at defining it.

I do think it's worthwhile for the spec to be open to other formats/assertions to be profiled over this same message exchange pattern.

One approach might be to change "2.6.2.  SAML Assertion Flow"  into  "2.7.  Assertion Flow" and then have a base "Assertion Flow" followed by a  "SAML Assertion flow"  that builds on the base by defining explicit values for assertion_format and assertion.   Essentially have a core protocol + 1 single SAML profile of that protocol in the spec.

-cmort

On 4/1/10 3:16 PM, "Eran Hammer-Lahav" <[email-masked]> wrote:

EHL

On Apr 1, 2010, at 16:34, "Chuck Mortimore" <[email-masked]> wrote:

-cmort

On 4/1/10 12:24 PM, "Eran Hammer-Lahav" <[email-masked] <mailto:[email-masked]> > wrote:

EHL

On 4/1/10 11:21 AM, "Marius Scurtescu" <[email-masked] <mailto:[email-masked]> > wrote:

Marius

On Wed, Mar 31, 2010 at 6:22 PM, Eran Hammer-Lahav <[email-masked] <mailto:[email-masked]> > wrote:
> http://github.com/theRazorBlade/draft-ietf-oauth/raw/master/draft-ietf-oauth <http://github.com/theRazorBlade/draft-ietf-oauth/raw/master/draft-ietf-oauth>
> .txt
>
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
>

---

From: Brian Eaton <[email-masked]>
Date: Thu, 1 Apr 2010 16:53:11 -0700

On Thu, Apr 1, 2010 at 3:38 PM, Chuck Mortimore
<[email-masked]> wrote:
> Flexibility.   If we lock Oauth2 down to one specific specific Assertion, it
> becomes unusable for other assertion formats.   Those assertion formats will
> evolve anyways.

Yep.  The SAML Web SSO profiles are living proof that something can be
underspecified (e.g. assertion details are vague), yet still widely
implemented and very useful.

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 1 Apr 2010 17:10:41 -0700

Are they profiling a half page spec?

EHL

---

From: Brian Eaton <[email-masked]>
Date: Thu, 1 Apr 2010 17:16:26 -0700

> Are they profiling a half page spec?

The spec is 66 pages long.  But the widely used pieces are quite a bit
shorter. =)

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 1 Apr 2010 21:02:11 -0700

This boils down to: if the flow cannot be used without further profile, and it is less than a page long, what's the value of putting it in the specification, as opposed to a fully specified extension? Or the alternative to provide one fully specified flow using the most common type of assertions (I'm not a SAML expert so I have no clue what that might be), and let others use that as a template.

But providing a half baked flow that is short enough to just replicate where needed and cannot be fully implemented by generic libraries doesn't really offer much.

I am not putting a stake in the ground on this but I am doing my job as editor to point out to the authors and users of this spec that as written, the flow is just not actually useful. It has the same value as if I posted it on my blog because to use it, someone will have to write a new spec that profiles it to an interop-capable setup.

EHL

On 4/1/10 5:16 PM, "Brian Eaton" <[email-masked]> wrote:

---

From: Marius Scurtescu <[email-masked]>
Date: Thu, 1 Apr 2010 21:45:38 -0700

On Thu, Apr 1, 2010 at 9:02 PM, Eran Hammer-Lahav <[email-masked]> wrote:
> But providing a half baked flow that is short enough to just replicate where
> needed and cannot be fully implemented by generic libraries doesn’t really
> offer much.

I think this is similar to the scope parameter argument, that
libraries cannot really
use an opaque scope. OAuth libraries will neither generate nor consume the
assertions, the assertion itself can be opaque. The client application needs to
obtain an assertion somehow, this is out of scope, then pass it to a library and
the library can use it as is, pass it to the Authorization Server and
deal with the
response. Works perfectly fine IMO.

Marius

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 1 Apr 2010 21:54:06 -0700

What is the assertion format? Binary? XML? Should the library encode it? Is the application using the library responsible for providing it with a URI-safe string?

EHL

On 4/1/10 9:45 PM, "Marius Scurtescu" <[email-masked]> wrote:

On Thu, Apr 1, 2010 at 9:02 PM, Eran Hammer-Lahav <[email-masked]> wrote:
> needed and cannot be fully implemented by generic libraries doesn't really
> offer much.

Marius

---

From: Marius Scurtescu <[email-masked]>
Date: Thu, 1 Apr 2010 22:00:44 -0700

On Thu, Apr 1, 2010 at 9:54 PM, Eran Hammer-Lahav <[email-masked]> wrote:
> What is the assertion format? Binary? XML? Should the library encode it? Is
> the application using the library responsible for providing it with a
> URI-safe string?

UTF-8 string I guess, the rest should not matter.

Marius

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 1 Apr 2010 22:10:16 -0700

The current draft allows the following characters:

  value-char  = ALPHA / DIGIT / "-" / "." / "_" / "~" / "%"

Which means a utf-8 string will need to be encoded somehow. Should it be percent-encoded? Something else?

EHL

On 4/1/10 10:00 PM, "Marius Scurtescu" <[email-masked]> wrote:

Marius

---

From: Chuck Mortimore <[email-masked]>
Date: Fri, 2 Apr 2010 07:31:21 -0700

For SAML it should be Base64 encoded.

-cmort
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Eran Hammer-Lahav [[email-masked]]
Sent: Thursday, April 01, 2010 10:10 PM
To: Marius Scurtescu
Cc: OAuth WG
Subject: Re: [OAUTH-WG] SAML Assertion Flow (was: Draft progress update)

EHL

Marius

---

From: Chuck Mortimore <[email-masked]>
Date: Fri, 2 Apr 2010 07:45:05 -0700

The format would be specified by a profilie.    For instance, a SAML profile might define:

assertion_format=urn:oasis:names:tc:SAML:2.0:cm:bearer
assertion={SAML 2 bearer assertion, optionally wrapped in a SAML response, Signature must cover the assertion and can be inherited from the Response signature, based64 encoded.  Subject format and attribute statement left undefined and implementation specific}

Some other implementation may want a SAML1.1 profile, or an Encrypted Assertion Profile, which would all be base64 encoded, but the details of the expected assertion would change. Someone may want to develop a Siteminder profile.   In this case, a siteminder session token would be exchanged for an Oauth token.   This would have a completely opaque format, and might be hex encode.    Someone else might want to develop an x.509 profile.   Etc, etc.

It really wouldn't be up to conformant Oauth2 clients to support these profiles, or even the core assertion profile for that matter.   As Marius points out, the method for obtaining/validating the assertions will be out of scope, and hence this is a specialized Oauth client/server you're dealing with by definition.

-cmort

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Eran Hammer-Lahav [[email-masked]]
Sent: Thursday, April 01, 2010 9:54 PM
To: Marius Scurtescu
Cc: OAuth WG
Subject: Re: [OAUTH-WG] SAML Assertion Flow (was: Draft progress update)

EHL

Marius

---

From: Chuck Mortimore <[email-masked]>
Date: Fri, 2 Apr 2010 07:54:40 -0700

Other profiles will be required.  The only point is to give these profiling specs clear guidelines on how they should approach the problem.

In any case, I get your point about what you want included in the core specification and why.   I'll put forth a proposal for the SAML format.

-cmort 

________________________________________
From: Eran Hammer-Lahav [[email-masked]]
Sent: Thursday, April 01, 2010 9:02 PM
To: Brian Eaton
Cc: Chuck Mortimore; OAuth WG
Subject: Re: [OAUTH-WG] SAML Assertion Flow (was: Draft progress update)

This boils down to: if the flow cannot be used without further profile, and it is less than a page long, what’s the value of putting it in the specification, as opposed to a fully specified extension? Or the alternative to provide one fully specified flow using the most common type of assertions (I’m not a SAML expert so I have no clue what that might be), and let others use that as a template.

But providing a half baked flow that is short enough to just replicate where needed and cannot be fully implemented by generic libraries doesn’t really offer much.

EHL

---

From: Chuck Mortimore <[email-masked]>
Date: Fri, 2 Apr 2010 08:07:40 -0700

In any case, I get your point about what you want included in the core specification and why.   I'll try and draft a proposal for the SAML format over the weekend and present it to the list.

-cmort 

EHL

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 2 Apr 2010 09:03:25 -0700

The problem with base64 (even the uri safe flavor) is the paddind  
character (=) is not allowed without percent encoding. This gets messy  
without clear encoding process.

The example below show that the profiles are likely to be much longer  
than the flow itself, raising my question of whether it is really all  
that useful to be included.

If we are going to keep this in the core spec we need a list of what a  
profile must specify (just the items, not the actual details) and we  
need an example. I can live with that.

Another option is to move it to a separate assertion flows spec which  
will include a few generally useful profiles.

EHL

On Apr 2, 2010, at 10:45, "Chuck Mortimore"  
<[email-masked]> wrote:

> assertion={SAML 2 bearer assertion, optionally wrapped in a SAML  
> response, Signature must cover the assertion and can be inherited  
> from the Response signature, based64 encoded.  Subject format and  
> attribute statement left undefined and implementation specific}
>
> Some other implementation may want a SAML1.1 profile, or an  
> Encrypted Assertion Profile, which would all be base64 encoded, but  
> the details of the expected assertion would change. Someone may want  
> to develop a Siteminder profile.   In this case, a siteminder  
> session token would be exchanged for an Oauth token.   This would  
> have a completely opaque format, and might be hex encode.    Someone  
> else might want to develop an x.509 profile.   Etc, etc.
>
> It really wouldn't be up to conformant Oauth2 clients to support  
> these profiles, or even the core assertion profile for that  
> matter.   As Marius points out, the method for obtaining/validating  
> the assertions will be out of scope, and hence this is a specialized  
> Oauth client/server you're dealing with by definition.
>
> -cmort
>
> What is the assertion format? Binary? XML? Should the library encode  
> it? Is the application using the library responsible for providing  
> it with a URI-safe string?
>
> EHL
>
>

---

From: Marius Scurtescu <[email-masked]>
Date: Fri, 2 Apr 2010 09:35:24 -0700

> percent-encoded? Something else?

Why do we have this limitation (sorry if I missed a discussion around this)?

Usernames and password, for example, are guaranteed to have problems.
I think it is much better for the protocol/libraries to take care of
encoding/decoding.

Marius

---

From: Chuck Mortimore <[email-masked]>
Date: Fri, 2 Apr 2010 09:45:36 -0700

Agreed on Base64, however the SAML already specifies this at it's encoding for web profiles, so we'll get the most reuse out of existing infrastructure by using it.   

I will work on an example - we should be able to make some sound decisions about how best to deal with it once we have something concrete.

thanks 

-cmort

________________________________________
From: Eran Hammer-Lahav [[email-masked]]
Sent: Friday, April 02, 2010 9:03 AM
To: Chuck Mortimore
Cc: Marius Scurtescu; OAuth WG
Subject: Re: [OAUTH-WG] SAML Assertion Flow (was: Draft progress update)

EHL

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 2 Apr 2010 12:00:47 -0700

Because of how we send parameters. Most of the problems we had with  
1.0 involved encoding issues. We just need to find a good way of  
explaining it.

These are the characters allowed in Uris and form encoded bodies.

EHL

On Apr 2, 2010, at 12:35, "Marius Scurtescu" <[email-masked]>  
wrote:

> On Thu, Apr 1, 2010 at 10:10 PM, Eran Hammer-Lahav <[email-masked] 
> > wrote:
>> Which means a utf-8 string will need to be encoded somehow. Should  
>> it be
>> percent-encoded? Something else?
>
>> On Thu, Apr 1, 2010 at 9:54 PM, Eran Hammer-Lahav <[email-masked] 
>> >
>> wrote:
>>> What is the assertion format? Binary? XML? Should the library  
>>> encode it?
>>> Is

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 02 Apr 2010 13:26:48 -0600

> I think it is much better for the protocol/libraries to take care of

/me watches in horror as a large can of worms is opened

---

From: Marius Scurtescu <[email-masked]>
Date: Fri, 2 Apr 2010 12:48:27 -0700

> These are the characters allowed in Uris and form encoded bodies.

Of course, but when you create the message you have to URL encode all
the name/value pairs, a library would do that for you. But the value
itself does not have to be restricted.

Are we trying to allow for naive encodings where you just string
together the names and values with some delimiters?

I don't think that will help at all, you are just pushing the need to
encode from the library out to the client code. And since the encoding
now is not specified you have a real interop issue IMO.

Marius

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Sat, 3 Apr 2010 13:08:39 -0700

I'm waiting to see what Brian has in mind for signatures. If we keep the OAuth 1.0a signature flow, we will need to deal with string encoding of some sorts. The current limitation has signature in mind, not transmitting requests.

But either way, since assertions have unique structures, it is important to note how they should be encoded into the request.

EHL

On 4/2/10 12:48 PM, "Marius Scurtescu" <[email-masked]> wrote:

Marius