Re: [security-services] Minutes from SSTC Call (Tuesday 22 November 2016) ---- RE: Proposed Agenda for SSTC Telecon (Tuesday 22 November 2016)

[Rainer Hoerbe <rainer@hoerbe.at>]

Hi Madalina,

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“.

re "Existing mechanisms for indicating the requested attributes depend on md:RequestedAttribute elements in metadata and samlp:AttributeConsumingServiceIndex in the samlp:AuthnRequest.“ 

Actually entity categories (https://github.com/iay/entity-category) are a second method for signaling pre-defined sets of requested attributes. While still not an RFC, they can me used to signal bundles of requested attributes. The same collision as with requested attributes would apply. @Scott: is it technically possible to reference an IETF-draft in an OASIS spec?

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.

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.  

Cheers, Rainer

Am 02.12.2016 um 10:46 schrieb Madalina Sultan <madalina.sultan@connectis.nl>:

Hi all,

I have made some changes to the document based on your input and added the Conformance section: https://www.oasis-open.org/apps/org/workgroup/security/download.php/59498

Regarding the metadata flag that announces support, the document currently states that it is optional. So it doesn't enforce anything. Do you think it will be more clear if I start from a specification like: "If an Identity Provider supports this extension, then it MUST define the metadata flag" ?

Regards,

Madalina

On Fri, Nov 25, 2016 at 6:23 PM, Cantor, Scott <cantor.2@osu.edu> wrote:

On 11/23/16, 4:39 PM, "Rainer Hoerbe" <rainer@hoerbe.at> wrote:

> I am not referring to the overhead in writing the spec, but for the user to understand and follow it.

I don't think this adds any meaningful complexity.

> In general it is better not to include stuff that is not used, reducing the burden on the reader. As said, if people
> thing they would like to announce capabilities in metadata, then the text should provide processing clues.

The common processing across all of metadata is that you look at it and base decisions on it. I don't know what we would need to say here beyond "if you don't see the attribute, don't send the extension", but that could certainly be said.

-- Scott

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.