Metadata support: EntitiesDescriptor/@Name handling

[Ian Young]

On 16 Aug 2013, at 21:25, "Cantor, Scott" <cantor.2 at osu.edu> wrote:

> On 8/16/13 4:20 PM, "Ian Young" <ian at iay.org.uk> wrote:
> 
>> For example, rather than turning something like @Name into faked-up SAML
>> metadata entity attributes, I'd favour essentially the opposite: have an
>> *object* metadata representation of the grouping concept, prime it with
>> the @Name hierarchy and provide a filter that extracts *that* from
>> user-specified *SAML* metadata entity attributes.
> 
> You could, for compatibility, but since our metadata constructs are
> entirely about SAML metadata, I don't know if that's more straightforward
> to explain or not. It seems like adding the filtering step is just adding
> a step.

I wasn't proposing that for compatibility as such.  I don't think we should regard it as a requirement to retain the current functionality of the match functors for relying party match (which currently includes the @Name hierarchy implicitly).  Indeed, I think Chad and I both felt that we wanted to separate the @Name thing out so that it wasn't being used by accident.  In the current context, I don't see any advantage in taking away the connection we have between @Name and relying party name and instead connecting it with entity attributes.  I'd rather see V3 implement each of these three things as entirely independent match functors.  All I was suggesting in the quote was that we could provide additional mechanisms to allow people to bridge @Name with either of the other mechanisms, but if we want it simple we'd just not do that and rely on the use of an explicit OR in policy rules.

	-- Ian



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4813 bytes
Desc: not available
Url : http://shibboleth.net/pipermail/dev/attachments/20130819/fdde80e8/attachment.bin