OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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

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?


> 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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]