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

[Torsten Lodderstedt <[e-mail]>]

  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:[e-mail]]
> *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:* [e-mail] <mailto:[e-mail]> 
> [mailto:[e-mail]] *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-mail]> wrote:
>
> WFM.
>
> > -----Original Message-----
> > From: Brian Campbell [mailto:[e-mail]]
> > 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-mail]> 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: [e-mail] [mailto:[e-mail]] 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
> > >> [e-mail]
> > >> https://www.ietf.org/mailman/listinfo/oauth
> > >
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>
>   
>   
> _______________________________________________
> OAuth mailing list
> [e-mail]  <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/oauth
>