[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)
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? 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
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]