Scott Cantor wrote:
>> Of course something like this is needed, no question about that. You
>> mention the relation to <AttributeConsumingService> at the outset, but
>> then you neglect to use <RequestedAttribute> in any of your proposed
>> solutions. Why not carry <RequestedAttribute> elements in the authn
>> request (in some way), with exactly the same semantics as in metadata?
>
> Yeah, I'd have to say that's always the solution I envisioned (with or
> without a new wrapper element).
I stand enlightened on this one. Yes, permitting multioccurrence
of <RequestedAttribute> inside <authnRequest> seems like
good solution. This even parallels the <RequestedAuthnContext>
nicely. The fact that <RequestedAttribute> is part of metadata
schema is not a problem, I presume.
Any opinions on the interrim solution?
Cheers,
--Sampo
> I'm not in favor of tunnelling. The existing query element is designed as
> a
> top level PDU and it's awkward to try to reuse it internally.
>
> Boxcarring is obviously an option, but should be at the binding level and
> that's a much bigger change that I would rather avoid if there's a simpler
> way.
>
>> The other thing I'll comment on is the proposed use of
>> Attribute/AttributeValue to convey non-attribute information to the
>> IdP. This too diverges from current usage, and I would suggest we
>> find some other way to carry this information.
>
> +1
>
> -- Scott
