[mdx] syntax for entity-attributes

[Ian Young]

On 22 Aug 2014, at 20:13, Tom Scavo <trscavo at gmail.com> wrote:

> On Fri, Aug 22, 2014 at 2:36 PM, Ian Young <ian at iay.org.uk> wrote:
>> 
>> On 22 Aug 2014, at 19:15, Tom Scavo <trscavo at gmail.com> wrote:
>> 
>>> Three years ago a syntax for entity attributes was proposed but that
>>> syntax is no longer compatible with the Metadata Query Protocol.
>> 
>> It's compatible
> 
> I don't think so because a leading "{" now has a special meaning.

You're right; I had forgotten that the proposed syntax used '{' as well, presumably because we were already using it for (at the time) "{sha1}" and "{md5}". That wouldn't be a problem for any similar syntax which used something other than '{', though.

>> it just doesn't have a defined meaning.
> 
> I don't know what you mean. An entityID in SAML metadata has a defined
> meaning but an entityID is just a special case of entity attribute so
> it seems reasonable to define a syntax for entity attributes as well.

I don't entirely buy the idea that even if you accept that entityIDs are a special case of entity attributes (and that's arguable, and indeed we've argued about it before) then it immediately makes sense to define syntax to represent selection on that basis. It's only reasonable, I think, to define such a syntax if you want to attach semantics to it: in other words, if you want to revisit the question of turning this into a search protocol. I still feel quite strongly that this is something that we do *not* want to do in either of these specs, although we might want to implement or profile something more specific later.

As Scott says, where we ended up last time round this loop was to observe that you can define any identifiers you like. They can even look like they have some kind of internal syntax associated with them if that's of assistance; but ultimately the identifiers presented to the query protocol are opaque and any apparent structure within them has no defined meaning, as I said before.

I've been reviewing the text in this area recently, and I have a somewhat related proposal which I think will clarify and improve this to some extent.

We've already refactored a lot of the "{sha1}" mechanism so that it is now mainly defined in the layered SAML document. However, I attempted to make a generic mechanism out of that; in retrospect I think that was the wrong approach. I now propose to state in the base document that an identifier (a thing passed to the query endpoint at .../entities/) may be any string of encodable characters (in ABNF, "1*idchar" instead of "notlb *idchar"[1]) and thus pushing all special cases out of that document into profiles, such as the SAML profile.

If you look at the current text:

https://github.com/iay/md-query/blob/master/draft-young-md-query.txt

... this would involve slicing out most of lines 313 to 363, and might even allow us to remove the ABNF reference from the base document altogether.

In the profile document, currently:

https://github.com/iay/md-query/blob/master/draft-young-md-query-saml.txt

... I don't think we'd need to change much if anything; we can still use the existing ABNF to describe the special case. There's a case to be made for reworking the way it talks about identifiers which means I think some of that text can be simplified and clarified, but I think that's independent and not important for the present discussion.

Back at the original question, this change would make it clear that any query syntax with semantics attached belongs in a profile. In terms of implementation, you can use identifiers that look like they have internal syntax without defining such a profile (there would be no bar to an identifier like "{foo=bar}") but as far as the *protocol* is concerned they are just opaque strings.

Comments on this proposal?

I'll be out of town and essentially offline for a few days, but hope to be spending a lot more time on this spec work starting around the middle of next week. I've learned quite a lot from building (or trying to build) a strict implementation.

	-- Ian

[1] actually, I think there's an argument for saying that it should just be "*idchar" -- allowing for an empty identifier and making "/entities/" equivalent to the result of "/entities" -- but that's probably worth leaving to one side for now.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5943 bytes
Desc: not available
URL: <http://lists.iay.org.uk/pipermail/mdx-iay.org.uk/attachments/20140828/81c4d384/attachment.bin>