Subject: [OAUTH-WG] Issue: specificity of the assertion flow

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

The assertion flow included in the specification doesn't offer enough to
provide interop. Previous discussions ruled out the idea of offering a
single SAML 2.0 based flow.

Proposal: Leave the flow as a generic assertion flow, using SAML 2.0 as an
example, and defining the syntax/values of the format parameter. As long as
the format parameter is well-defined, the rest can be left for
assertion-language-specific specs and implementations.

Needed: Language defining the format parameter in a way which ensures
interop across clients using the same format value (i.e. Registry,
URI-based, etc).

EHL

---

From: Chuck Mortimore <[email-masked]>
Date: Thu, 15 Apr 2010 11:55:53 -0700

+1.

Did anyone have a chance to review the proposal I made here?    I have a couple of people from the SAML community reviewing it offline, but would welcome feedback from this group.   The sample text is attached to this post:

http://www.ietf.org/mail-archive/web/oauth/current/msg01735.html

One specific thing to note - the assertion flow is really appropriate for both autonomous and on-behalf-of user flows, so it will take some special editing to make that work with the current structure of the intro.

-cmort

On 4/15/10 11:02 AM, "Eran Hammer-Lahav" <[email-masked]> wrote:

EHL

_______________________________________________
OAuth mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/oauth

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 15 Apr 2010 12:00:19 -0700

If I recall correctly, it doesn't define the format parameter, just gives one fixed value for the SAML flow. Either way, I am suggesting we keep the SAML flow out of the spec, keeping just the general assertion flow, with better format definition.

EHL

On 4/15/10 11:55 AM, "Chuck Mortimore" <[email-masked]> wrote:

+1.

-cmort

EHL

---

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

Not at all...the submission is largely focused on the generic assertion flow.  It simply adds additional detail to the current text, and clarifies/corrects some of the expected usage patterns.   There is a SAML profiling of the flow at the end of the submission, but it's a small percentage of what I submitted.

In terms of format, it suggests:

    format
         REQUIRED. The format of the assertion as defined by the authorization server.  The format MUST be a URI which designates a profile of the assertion flow.

I personally think this is all that is required.   It would be nice if these were addressable URIs, but in practice that doesn't happen often, and it does leave behind some specs which are using urn's.

Could you please take another glance at what I posted?   There are a number of changes to the general assertion flow that are required for it to reflect how this will be used in a lot of scenarios.   Specifically, it:

 *   Changes the text so the flow is appropriate for on-behalf-of user flows as well as autonomous, illustrates usage patterns, and indicates this is simply a basis for consistent profiling
 *   Adds a bit of detail on parameters in terms of what's required, format, etc.
 *   Specifies that error responses defined in a profile may supersede those in the general assertion flow
 *   Removes the text around reusing assertions when requesting new access tokens, as some assertion profiles may be single use assertions; this should be up to the profile.

So - this works for me - a generic flow is what I was suggesting to begin with.   The SAML profiling can happen elsewhere if an example profile is not required.

Thanks

-cmort

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

EHL

+1.

-cmort

EHL

---

From: Brian Eaton <[email-masked]>
Date: Fri, 16 Apr 2010 17:03:38 -0700

On Thu, Apr 15, 2010 at 12:38 PM, Chuck Mortimore
<[email-masked]> wrote:
> Could you please take another glance at what I posted?   There are a number
> of changes to the general assertion flow that are required for it to reflect
> how this will be used in a lot of scenarios.

>  (A)  The client sends an access token request to the authorization server and includes a self-issued assertion.

Why self issued?

> The value of the assertion parameter MUST be a valid SAML <Response> message

Why saml Response instead of saml Assertion?

Scope would be useful in this profile.

Adding form-encoded content-type header to the examples would be useful.

Cheers,
Brian

---

From: Chuck Mortimore <[email-masked]>
Date: Fri, 16 Apr 2010 17:19:45 -0700

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

Why self issued?

> It really can be either, and I see now that's not really clear here.   The client may have the ability to directly issue the SAML assertion, rather than having to fetch it from a server.     In short, the profile doesn't care about where the assertion came from, as long as it validates, and I was attempting to convey that.  This is likely confusing and probably needs re-wording.

> I was really back and forth on this one.   I scoped it down to Response for simplicity, but I've spoken to enough people offline that I think I probably made the wrong choice.  A new suggestion would be:  "The value of the assertion parameter MUST contain a valid SAML Assertion.   The SAML Assertion MAY be enclosed in a valid SAML Response.  If enclosed in a SAML Response, the Assertion MAY inherit it's signature from the Response per SAML Core 5.3"

Cheers,
Brian

> Thanks for reviewing this.

-cmort