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] 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

Am 23.11.2016 um 14:42 schrieb Madalina Sultan <madalina.sultan@connectis.nl>:

Hi all, 

I have uploaded a new version of the document, it can be found here: https://www.oasis-open.org/apps/org/workgroup/security/document.php?document_id=59439

Scott/Rainer - could you please look over it and let me know if it now covers all your comments?

Regards,
Madalina


This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. Connectis accepts no liability for damage of any kind resulting from the risks inherent in the electronic transmission of messages.



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