[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [security-services] Minutes from SSTC Call (Tuesday 22 November 2016) ---- RE: Proposed Agenda for SSTC Telecon (Tuesday 22 November 2016)
I doubt the value of a general metadata extension announcing the support of this extension. Is there a use case where an SP would select IDPs based on it? SPs may send extensions in the AutnRequest regardless of the IDP supporting it, and IDP must ignore them if not understood. Also, the SP must check if all mandatory attributes have been included when receiving the Assertion, so in case something is missing that should be the right point in time to handle the exception. And the IDP might release the requested attributes anyway, even without supporting the extension. OTOH, if there is a solid case for the metadata extension, the processing rules and semantics should be explained. Another point: While requesting attributes via metadata is less flexible than the extension under discussion, it covers most use cases and is much more efficient in processing terms. Therefore the text in 2.2 should include some language like this: „For services that request a static set of attributes for most or all requests the signaling of requested attributes should be done via metadata (either with the AssertionConsumerervice or even simpler in an EntityCategory).“ Cheers, Rainer
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]