[mdx] syntax for entity-attributes

[Tom Scavo]

On Thu, Aug 28, 2014 at 10:33 AM, Ian Young <ian at iay.org.uk> wrote:
>
> On 22 Aug 2014, at 20:13, Tom Scavo <trscavo at gmail.com> wrote:
>>
>> 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)

So I'll resist the urge to argue the point again :-) but for me it's a given.

> 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

I really don't see why that is.

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

I strongly agree with your strong feelings against a search protocol
;-) but what does that have to do with a syntax for entity attributes.
The latter is an agreed upon syntax for a particular aggregate (not
unlike the proposal for a syntax for the "all entities" aggregate),
which seems to me to be a rather Good Thing.

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

Yup, okay, I can buy that. Can we say the same about the "all
entities" aggregate? Or do you think that's fundamentally different in
some way?

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

Hmm. What if a server chooses to support the "{sha1}" mechanism only,
leaving the client to do the mapping (say, with JavaScript)? I don't
think we want to force the mapping on the server, do we? (In fact, we
have a deployed client-server setup based exactly on this assumption.
The server implementation is intentionally "brain dead" in our case.)

> Comments on this proposal?

I think we're too early in the deployment phase to be making firm
decisions (but we should continue to discuss, to be sure). Methinks
the spec should bake for awhile as folks get more experience deploying
this stuff.

Ian, thanks for all your efforts in this space.

Tom