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:tors...@lodderstedt.net]
*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.
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:* oauth-boun...@ietf.org <mailto:oauth-boun...@ietf.org>
[mailto:oauth-boun...@ietf.org] *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?
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" <e...@hueniverse.com> wrote:
WFM.
> -----Original Message-----
> From: Brian Campbell [mailto:bcampb...@pingidentity.com]
> 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
> 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?
>
>
>
> On Mon, Aug 9, 2010 at 10:43 PM, Eran Hammer-Lahav
> <e...@hueniverse.com> wrote:
> > 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: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] 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 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%2Fa
> sse
> >> rtion_type%2Fsaml%2F2.0%2Fbearer&assertion=[...1st
> >> assertion...]&assertion=
> >> [...2nd assertion...]&assertion=[...3nd assertion...]
> >> _______________________________________________
> >> OAuth mailing list
> >> OAuth@ietf.org
> >> https://www.ietf.org/mailman/listinfo/oauth
> >
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
