Re: [security-services] Proposal: Query Extension for SAML AuthnReq

["Tom Scavo" <trscavo@gmail.com>]

On Mon, May 5, 2008 at 11:33 AM, Paul Madsen <paulmadsen@rogers.com> wrote:
> A thought. The possibility of embedding <RequestedAttribute> in an
> <AuthnRequest> might be seen as an 'enabler' of the current (to my mind)
> kludge of using attributes in an IDP-issued assertion to carry assurance.

It is a kludge, and this will make it easier, yes.  But really, what
choice do you have in deployments that support SAML V1.1 and V2.0?
The lowest common denominator is the attribute, which I think is why
you see this happening.

>  The existing inability of an SP to ask for particular 'assurance
> attributes' in its <AuthnRequest> would presumably be one driver for them to
> instead use <RequestedAuthnContext>?

You're assuming of course that LoA is only required by SAML V2.0
deployments, which of course isn't the case.

>  Should we give guidance against such an application of the new extension?

No, I would say not.  Even if the above points were not true, Sampo's
profile is not the place to "enforce" this practice.

Just my two cents worth,

Tom

>  Tom Scavo wrote:
>
> > On Fri, Apr 25, 2008 at 10:52 PM, Scott Cantor <cantor.2@osu.edu> wrote:
> >
> >
> > >  > Any opinions on the interrim solution?
> > >
> > >  Probably we would need some normative language about whether to treat
> the
> > >  extension as mandatory (meaning if you understand it, do you return an
> error
> > >  if you can't satisfy the attribute request?). Currently the metadata
> > >  equivalent is expressly optional to enforce.
> > >
> > >
> >
> > So there will be two methods of requesting attributes in conjunction
> > with <samlp:AuthnRequest>:
> >
> > 1. By reference via AttributeConsumingServiceIndex
> > 2. By value via <md:RequestedAttribute>
> >
> > Scott is working on (1) in conjunction with errata, and Sampo has
> > proposed (2).  In the end, the two approaches should be semantically
> > equivalent, that is, the normative language describing each approach
> > should be the same.
> >
> > Tom
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe from this mail list, you must leave the OASIS TC that
> > generates this mail.  You may a link to this group and all your TCs in
> OASIS
> > at:
> > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
> >
> >
> >
> >
>
>  --
>  Paul Madsen            e:paulmadsen @ ntt-at.com
>  NTT                    p:613-482-0432
>                       m:613-282-8647
>                       aim:PaulMdsn5
>                       web:connectid.blogspot.com
>