On Mon, May 5, 2008 at 11:33 AM, Paul Madsen <> 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 <> 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
>
