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.
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>?
Should we give guidance against such an application of the new extension?
Paul
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
