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)


Just uploaded another version here: https://www.oasis-open.org/apps/org/workgroup/security/download.php/59533/saml-protoc-req-attr-req-v1.0-wd02.pdf 

Hope it answers your comments now :)

Thanks for the feedback! 


On Tue, Dec 6, 2016 at 3:55 PM, Madalina Sultan <madalina.sultan@connectis.nl> wrote:
Hi Rainer,

re „Per Request“. 
The term is not precise, because including an acs-index in a request is also a per-request choice. What you actually oppose is ad-hoc vs. pre-defined attribute requests. Therefore I suggest to rename the extension to „requesting ad-hoc sets of attributes“.

I understand your concern and you are right. I would prefer to do what Scott suggested and adjust the text so that the ad-hoc intent becomes clearer. 

re "If an Identity Provider receives from a non-compliant Service Provider an AuthenticationRequest containing both a <samlp:AttributeConsumingServiceIndex> and a <req-attr:RequestedAttributes>
Postel’s law („.. be liberal in what you accept from others) is good for interoperability, but in this case it may hide a semantic contradiction. My preference would be to return an error, but if you think that the intention of the sender is clear and requested attributes should always override acs index, then you could specify it from beginning. Consider the behavior if the ACS has no requested Attributes, and if attribute sets are not overlapping.

What I actually wanted was that ACS Index override requested attributes, in case both options are used in the same request. I will rephrase that section, since it still seems to be confusing.

re "SAML Metadata MAY be used to indicate support for this protocol extension“. I doubt that this is useful unless it is mandatory, because if an entity really needs this information, it has to poll it somewhere else to be complete.  

As Scott mentioned, tehnically I can't enforce the usage of that flag. I looked over several others OASIS extensions that use this kind of flag and only found the MAY word. 

I'll update my document based on your feedback.

Best regards,

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]