Subject: [OAUTH-WG] more than one assertion?

From: Brian Campbell <[email-masked]>
Date: Mon, 9 Aug 2010 13:33:51 -0600

The question of allowing for multiple assertions in the SAML profile
came up recently.  See
http://www.ietf.org/mail-archive/web/oauth/current/msg04068.html and
several subsequent messages in the thread.

I pushed back on the idea at first due to added complexity.  There are
a number of things that need to be addressed that aren't present in
the single assertion case.   One of the sticker ones, to me, was how
to encode the assertions into the request.   A SAML <Response> element
is a nice container for multiple assertions but using it in this
context seemed awkward at best.  A new schema could be defined or a
special deliminator character could be used but that seems excessive
and kludgy respectively.

What about pushing it up into the HTTP layer and allowing for multiple
occurrences of the assertion=XXX parameter in the POST body?  I don't
see anything in core OAuth that would necessarily preclude doing this.
 It seems cleaner and more lightweight than some of the other options.
 And perhaps it could be a more general (not just SAML) method of
sending multiple assertions in a single assertion grant type request?

It'd look something like this:

  POST /token.oauth2 HTTP/1.1
  Host: authz.example.net
  Content-Type: application/x-www-form-urlencoded

   grant_type=assertion&assertion_type=http%3A%2F%2Foauth.net%2Fasse
   rtion_type%2Fsaml%2F2.0%2Fbearer&assertion=[...1st assertion...]&assertion=
   [...2nd assertion...]&assertion=[...3nd assertion...]

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 9 Aug 2010 21:43:55 -0700

Do we need to clarify 4.3.1 "repeats a parameter" description for "invalid_request" error code does not preclude parameters from repeating? I'm not sure.

EHL

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Brian Campbell
> Sent: Monday, August 09, 2010 12:34 PM
> To: oauth
> Subject: [OAUTH-WG] more than one assertion?
> 
> The question of allowing for multiple assertions in the SAML profile came up
> recently.  See http://www.ietf.org/mail-
> archive/web/oauth/current/msg04068.html and several subsequent
> messages in the thread.
> 
> I pushed back on the idea at first due to added complexity.  There are a
> number of things that need to be addressed that aren't present in
> is a nice container for multiple assertions but using it in this context seemed
> awkward at best.  A new schema could be defined or a special deliminator
> character could be used but that seems excessive and kludgy respectively.
> 
> occurrences of the assertion=XXX parameter in the POST body?  I don't see
> anything in core OAuth that would necessarily preclude doing this.
>  And perhaps it could be a more general (not just SAML) method of sending
> multiple assertions in a single assertion grant type request?
> 
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Brian Campbell <[email-masked]>
Date: Tue, 10 Aug 2010 10:02:56 -0600

To be honest, I somehow overlooked that particular text - my mistake
and apologies. Reading it again, it probably does preclude parameters
from repeating, however, I can see some room for varied
interpretations as to if that's a strong normative requirement or a
looser suggestion about an error code that could be used in that
circumstance.

Perhaps it could be made more clear by adding some wording about it to
the end of the first part of sections 3&4 where it says: "Parameters
sent without a value MUST be treated as if they were omitted from the
request.  The authorization server SHOULD ignore unrecognized request
parameters."?

That said, does it make sense to relax the ban on repeating parameters
in some situations, like for the assertion parameter, to facilitate
easy encoding of multiple assertions?   Anthony (Tony?) Nadalin
suggested that multiple assertions might be a common use case and I
think allowing for that via repeating assertion parameters is a
cleaner and more reusable way to do it.

The text at the bottom of section for could say something like:

"Parameters sent without a value MUST be treated as if they were
omitted from the request.  The authorization server SHOULD ignore
unrecognized request parameters.  Parameters MUST NOT repeat unless
otherwise noted in the parameter definition."

Then in 4.1.3. the assertion parameter could be something like this:

  "assertion
         REQUIRED.  The assertion(s).  This parameter MAY be repeated
in the request,  if more than one
          assertion is needed for the access grant"

Obviously Eran could improve on the actual text but hopefully that
gets the concept across?

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 10 Aug 2010 09:15:03 -0700

WFM.

> From: Brian Campbell [mailto:[email-masked]]
> Sent: Tuesday, August 10, 2010 9:03 AM
> To: Eran Hammer-Lahav
> Cc: oauth
> Subject: Re: [OAUTH-WG] more than one assertion?
> 
> To be honest, I somehow overlooked that particular text - my mistake and
> apologies. Reading it again, it probably does preclude parameters from
> repeating, however, I can see some room for varied interpretations as to if
> that's a strong normative requirement or a looser suggestion about an error
> code that could be used in that circumstance.
> 
> Perhaps it could be made more clear by adding some wording about it to the
> end of the first part of sections 3&4 where it says: "Parameters sent without
> a value MUST be treated as if they were omitted from the request.  The
> authorization server SHOULD ignore unrecognized request parameters."?
> 
> That said, does it make sense to relax the ban on repeating parameters in
> some situations, like for the assertion parameter, to facilitate
> suggested that multiple assertions might be a common use case and I think
> allowing for that via repeating assertion parameters is a cleaner and more
> reusable way to do it.
> 
> "Parameters sent without a value MUST be treated as if they were omitted
> from the request.  The authorization server SHOULD ignore unrecognized
> request parameters.  Parameters MUST NOT repeat unless otherwise noted
> in the parameter definition."
> 
>          REQUIRED.  The assertion(s).  This parameter MAY be repeated in the
> request,  if more than one
> Obviously Eran could improve on the actual text but hopefully that gets the
> concept across?
> 
> 
> 
> > Do we need to clarify 4.3.1 "repeats a parameter" description for
> "invalid_request" error code does not preclude parameters from repeating?
> I'm not sure.
> >
> > EHL
> >
> >> From: [email-masked] [mailto:[email-masked]] On
> >> Behalf Of Brian Campbell
> >> came up recently.  See http://www.ietf.org/mail-
> >> I pushed back on the idea at first due to added complexity.  There
> >> are a number of things that need to be addressed that aren't present
> >> in the single assertion case.   One of the sticker ones, to me, was
> >> how to encode the assertions into the request.   A SAML <Response>
> >> element is a nice container for multiple assertions but using it in
> >> this context seemed awkward at best.  A new schema could be defined
> >> or a special deliminator character could be used but that seems excessive
> and kludgy respectively.
> >>
> >> What about pushing it up into the HTTP layer and allowing for
> >> multiple occurrences of the assertion=XXX parameter in the POST body?
> >> I don't see anything in core OAuth that would necessarily preclude doing
> this.

---

From: Chuck Mortimore <[email-masked]>
Date: Thu, 12 Aug 2010 10:24:12 -0700

Personally, I'd first like to see more concrete use-cases of how multiple assertions are going to be used in practice.   Tony alluded to some abstract use-cases, but fuller descriptions would probably help everyone out.

-cmort

On 8/10/10 9:15 AM, "Eran Hammer-Lahav" <[email-masked]> wrote:

WFM.

---

From: David Recordon <[email-masked]>
Date: Thu, 12 Aug 2010 15:36:09 -0400

I've only been half following the recent assertion threads for this
exact reason. I don't understand how these proposals are going to be
used and worry about any additional complexity added to the spec.

--David

On Thu, Aug 12, 2010 at 1:24 PM, Chuck Mortimore
<[email-masked]> wrote:
> Personally, I’d first like to see more concrete use-cases of how multiple
> assertions are going to be used in practice.   Tony alluded to some abstract
> use-cases, but fuller descriptions would probably help everyone out.
>
> -cmort
>
>

---

From: Brian Eaton <[email-masked]>
Date: Thu, 12 Aug 2010 12:38:12 -0700

> used and worry about any additional complexity added to the spec.

Likewise.

---

From: Brian Campbell <[email-masked]>
Date: Thu, 12 Aug 2010 14:01:52 -0600

I generally agree more with Chuck, David and Brain E than I don't.
But I do think that someone will find a pragmatic reason for > 1
assertion eventually and I think the proposal earlier in this thread
to allow for multiple occurrences of the assertion parameter in the
core spec will make that easier for a number of instantiations of the
assertion flow (grant type) at a later time.  It adds some complexity
but I don't think a lot.  And specifications or pairwise agreements
building on the assertion flow could easily constrain down to a single
assertion, if it suits the profile.

That's the only change proposal to the core spec that's come out of
discussion around my I-D
http://www.ietf.org/id/draft-campbell-oauth-saml-00.txt (that I can
think of).  I'm still not sure if it makes sense to allow for multiple
assertions in the next draft of that, but allowing for multiple
assertion params in core sure seems like a cleaner way to do it.

Yaron's proposal for a Section 2.2 on Client Assertions is a change to
core as well (latest in that thread:
http://www.ietf.org/mail-archive/web/oauth/current/msg04154.html).
However, even though it uses the term assertion similarly, it's a
distinct issue from the SAML work.  The latter is a SAML based usage
of the assertion grant type while the former I think of it more as a
means of allowing for stronger forms of client authentication than
just a client password/secret.

I guess both could be used in a two-legged style interaction (or used
together) and maybe that's where it starts to get confusing...

---

From: David Recordon <[email-masked]>
Date: Thu, 12 Aug 2010 16:04:48 -0400

Given that, would you strongly object to these proposals being written
in a separate document than the core spec? The device flow is a good
example of where we're doing this. We really think that it will be
useful, are working on implementations, but it hasn't yet been proven
in production.

---

From: Torsten Lodderstedt <[email-masked]>
Date: Fri, 13 Aug 2010 09:50:22 +0200

multiple (SAML) assertions also mean multiple subject statements. Are there any constraints regarding the relations among those subjects (identities)? 

regards,
Torsten.

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 13 Aug 2010 11:28:30 -0700

The only change I'm aligned with is being more specific about repeating parameters and potentially allowing the assertion parameter to repeat. That's it for the core spec. The SAML spec should be more specific about allowing or not multiple assertions for the given type URI.

EHL

> From: David Recordon [mailto:[email-masked]]
> Sent: Thursday, August 12, 2010 12:36 PM
> To: Chuck Mortimore
> Cc: Eran Hammer-Lahav; Brian Campbell; oauth
> I've only been half following the recent assertion threads for this exact
> reason. I don't understand how these proposals are going to be used and
> worry about any additional complexity added to the spec.
> 
> --David
> 
> 
> > Personally, I'd first like to see more concrete use-cases of how
> > multiple assertions are going to be used in practice.   Tony alluded
> > to some abstract use-cases, but fuller descriptions would probably help
> everyone out.
> >
> > -cmort
> >
> >
> >> Perhaps it could be made more clear by adding some wording about it
> >> to the end of the first part of sections 3&4 where it says:
> >> unrecognized request parameters."?
> >>
> >> That said, does it make sense to relax the ban on repeating
> >> parameters in some situations, like for the assertion parameter, to
> >> facilitate easy encoding of multiple assertions?   Anthony (Tony?)
> >> Nadalin suggested that multiple assertions might be a common use case
> >> and I think allowing for that via repeating assertion parameters is a
> >> >> The question of allowing for multiple assertions in the SAML
> >> >> profile came up recently.  See http://www.ietf.org/mail-
> >> >> are a number of things that need to be addressed that aren't
> >> >> present in the single assertion case.   One of the sticker ones,
> >> >> to me, was how to encode the assertions into the request.   A SAML
> >> >> <Response> element is a nice container for multiple assertions but
> >> >> using it in this context seemed awkward at best.  A new schema
> >> >> could be defined or a special deliminator character could be used
> >> >> but that seems excessive
> >> and kludgy respectively.
> >> >>

---

From: Brian Campbell <[email-masked]>
Date: Fri, 13 Aug 2010 13:58:14 -0600

On Fri, Aug 13, 2010 at 12:28 PM, Eran Hammer-Lahav <[email-masked]> wrote:
> The only change I'm aligned with is being more specific about repeating parameters
> and potentially allowing the assertion parameter to repeat. That's it for the core spec.

Thanks for clarifying that Eran.  That's the only change I was
suggesting here.  And if others think it's too complicated, I'm not
married to it.  Just seemed like a potentially useful thing.

> The SAML spec should be more specific about allowing or not multiple assertions for the given type URI.

Yes, and it will be.

---

From: Brian Campbell <[email-masked]>
Date: Fri, 13 Aug 2010 14:55:04 -0600

> useful, are working on implementations, but it hasn't yet been proven

The assertion flow should stay in core (others have expressed this
opinion as well).  I've got interop tested code built on that that is
about to GA.

As far as the client assertions, I do believe there's real value in
having a clean extension point for stronger forms of client
authentication.  Yaron's proposed language does a pretty good job I
think.  But if it can be done in a simpler way, let's discuss. I'll
probably regret saying this, but what about not using the word
"assertion" for stronger client auth options?  That might help
eliminate some confusion.

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 18 Aug 2010 00:20:07 -0700

The assertion flow has been "upgraded" from an edge case to the way new access grants are defined. It's part of the extensibility model, and as such, is going to stay in the core spec.

EHL

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Brian Campbell
Sent: Friday, August 13, 2010 1:55 PM
To: David Recordon
Cc: oauth
Subject: Re: [OAUTH-WG] more than one assertion?

> useful, are working on implementations, but it hasn't yet been proven 

The assertion flow should stay in core (others have expressed this opinion as well).  I've got interop tested code built on that that is about to GA.

As far as the client assertions, I do believe there's real value in having a clean extension point for stronger forms of client authentication.  Yaron's proposed language does a pretty good job I think.  But if it can be done in a simpler way, let's discuss. I'll probably regret saying this, but what about not using the word "assertion" for stronger client auth options?  That might help eliminate some confusion.
_______________________________________________
OAuth mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/oauth

---

From: Anthony Nadalin <[email-masked]>
Date: Fri, 20 Aug 2010 18:19:15 +0000

So the UK Government Gateway project is a concrete use case. The use case for the UK government is that the government has many assertion providers; this is due to both legal and historical reasons. The first assertion provider is UK Department of Works and Pension (DWP), the second one is Department of Motor Vehicles and the third is the Department of Revenue (and so on ...). A citizen may need and assertion from each one of these government departments attesting to various things. A person wants a parking permit, so DWP and Department of Motor Vehicles are involved; DWP is the authoritative source of address and DMV is the authoritative source of vehicle information. So in order to obtain a parking permit, I have to live on the street that I obtain the parking permit for and I also need to own the vehicle for which I'm obtaining the parking permit. So these 2 assertions under different subject identifiers would have to be submitted to obtain the parking permit. So there has to be a way to carry the 2 assertions to obtain the token to get the parking permit.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Chuck Mortimore
Sent: Thursday, August 12, 2010 10:24 AM
To: Eran Hammer-Lahav; Brian Campbell
Cc: oauth
Subject: Re: [OAUTH-WG] more than one assertion?

-cmort

---

From: Torsten Lodderstedt <[email-masked]>
Date: Fri, 20 Aug 2010 20:29:19 +0200

What data shall the issued token contain? Different identifiers and 
also information about the different issuing authorities? Is the new 
token's data inherited from the source assertions or are the assertions 
just verified and the token data (incl. identity) are from other sources?

What do you think about the following alternatives?
- issue one access token per assertion and send all tokens to the target 
service
- directly send the assertions to the target service (underlying 
question: what is the benefit of converting assertions into tokens?)

regards,
Torsten.

Am 20.08.2010 20:19, schrieb Anthony Nadalin:
>
> So the UK Government Gateway project is a concrete use case. The use 
> case for the UK government is that the government has many assertion 
> providers; this is due to both legal and historical reasons. The first 
> assertion provider is UK Department of Works and Pension (DWP), the 
> second one is Department of Motor Vehicles and the third is the 
> Department of Revenue (and so on ...). A citizen may need and 
> assertion from each one of these government departments attesting to 
> various things. A person wants a parking permit, so DWP and Department 
> of Motor Vehicles are involved; DWP is the authoritative source of 
> address and DMV is the authoritative source of vehicle information. So 
> in order to obtain a parking permit, I have to live on the street that 
> I obtain the parking permit for and I also need to own the vehicle for 
> which I'm obtaining the parking permit. So these 2 assertions under 
> different subject identifiers would have to be submitted to obtain the 
> parking permit. So there has to be a way to carry the 2 assertions to 
> obtain the token to get the parking permit.
>
> *From:* [email-masked] [mailto:[email-masked]] *On 
> Behalf Of *Chuck Mortimore
> *Sent:* Thursday, August 12, 2010 10:24 AM
> *To:* Eran Hammer-Lahav; Brian Campbell
> *Cc:* oauth
> *Subject:* Re: [OAUTH-WG] more than one assertion?
>
> to some abstract use-cases, but fuller descriptions would probably 
> help everyone out.
>
> -cmort
>
>
> to the
> gets the

---

From: "Zeltsan, Zachary (Zachary)" <[email-masked]>
Date: Fri, 20 Aug 2010 16:11:21 -0500

This is a convincing use in support of the multiple assertions.
My understanding is that in the use case the two assertions provide the different statements of the different issuers regarding the same subject (the person seeking a parking permit). Is there a use case that requires multiple assertions regarding different subjects?

Zachary

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Anthony Nadalin
Sent: Friday, August 20, 2010 2:19 PM
To: Chuck Mortimore; Eran Hammer-Lahav; Brian Campbell
Cc: oauth
Subject: Re: [OAUTH-WG] more than one assertion?

-cmort

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Sat, 21 Aug 2010 22:21:35 -0700

This is a very interesting use case.

However, it is far from being as well-defined as the single SAML assertion flow proposed (and implemented!). Surely, satisfying these requirements goes far beyond being able to include more than one assertion.
At this point I only support additional language that allows assertion extensions to define the meaning of duplicated parameters (in general, not the assertion parameter specifically). When the server sees an access grant type of assertion and a given assertion type URI, it will know how to deal with duplication (such as multiple assertions provided as repeated parameters) via the specification defining this assertion type.

Regardless, repeating parameters is simply a bad idea that will certainly lead to problems with existing framework incapable of handling such a conflict.

EHL

From: Anthony Nadalin [mailto:[email-masked]]
Sent: Friday, August 20, 2010 11:19 AM
To: Chuck Mortimore; Eran Hammer-Lahav; Brian Campbell
Cc: oauth
Subject: RE: [OAUTH-WG] more than one assertion?

-cmort

---

From: Anthony Nadalin <[email-masked]>
Date: Mon, 30 Aug 2010 22:53:43 +0000

The sets of use case that we have on various ongoing projects just have a single subject (note that the single subject will be known by different identifiers since there are jurisdictional requirements for this).

From: Zeltsan, Zachary (Zachary) [mailto:[email-masked]]
Sent: Friday, August 20, 2010 2:11 PM
To: Anthony Nadalin; Chuck Mortimore; Eran Hammer-Lahav; Brian Campbell
Cc: oauth
Subject: RE: [OAUTH-WG] more than one assertion?

Zachary

-cmort

---

From: Anthony Nadalin <[email-masked]>
Date: Mon, 30 Aug 2010 23:54:32 +0000

The issues token may contain different subject identifiers which come from different issuing authorities; the new token may inherit from the source assertions (aggregated) or these may be verified and passed on, there are cases where both are methods are used.  So we have thought about multiple tokens,, this winds up being more complicated and traffic, the reason to not send directly is for user consent.

From: Torsten Lodderstedt [mailto:[email-masked]]
Sent: Friday, August 20, 2010 11:29 AM
To: Anthony Nadalin
Cc: Chuck Mortimore; Eran Hammer-Lahav; Brian Campbell; oauth
Subject: Re: [OAUTH-WG] more than one assertion?

What data shall the issued token contain? Different identifiers and also information about the different issuing authorities? Is the new token's data inherited from the source assertions or are the assertions just verified and the token data (incl. identity) are from other sources?

What do you think about the following alternatives?
- issue one access token per assertion and send all tokens to the target service
- directly send the assertions to the target service (underlying question: what is the benefit of converting assertions into tokens?)

regards,
Torsten.

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Chuck Mortimore
Sent: Thursday, August 12, 2010 10:24 AM
To: Eran Hammer-Lahav; Brian Campbell
Cc: oauth
Subject: Re: [OAUTH-WG] more than one assertion?

-cmort

OAuth mailing list

[email-masked]<mailto:[email-masked]>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Tue, 31 Aug 2010 09:36:29 +0200

User consent in the assertion flow? How do you envision to acquire the 
user consent?

Am 31.08.2010 01:54, schrieb Anthony Nadalin:
>
> The issues token may contain different subject identifiers which come 
> from different issuing authorities; the new token may inherit from the 
> source assertions (aggregated) or these may be verified and passed on, 
> there are cases where both are methods are used.  So we have thought 
> about multiple tokens,, this winds up being more complicated and 
> traffic, the reason to not send directly is for user consent.
>
> *From:* Torsten Lodderstedt [mailto:[email-masked]]
> *Sent:* Friday, August 20, 2010 11:29 AM
> *To:* Anthony Nadalin
> *Cc:* Chuck Mortimore; Eran Hammer-Lahav; Brian Campbell; oauth
> token's data inherited from the source assertions or are the 
> assertions just verified and the token data (incl. identity) are from 
> other sources?
>
> *From:* [email-masked] <mailto:[email-masked]> 
> [mailto:[email-masked]] *On Behalf Of *Chuck Mortimore
> [email-masked]  <mailto:[email-masked]>