[mdx] Metadata Retrieval Protocol, WD03

[Chad La Joie]

On 5/25/10 5:35 PM, Leif Johansson wrote:
> I started in on an implementation a couple of days ago and came up with
> two things I'm missing from this:
>
> 1. Multiple collection identifiers/tags. I think we will need to be able
> to express "InC+Silver" or "SWAMID+testing" or "haka+production+
> dreamspark" and both for collections and for individual entities...
>
> For instance federation operators will need to allow IdPs to opt-in to
> certain metadata-feeds - for instance when IdPs are required to fulfill
> extra requirements to play well with the SP.
>
> I think we could do this by using the del.icio.us URL pattern
>
> <base_url>/entity-collection/{id1}+{id2}+...
>
> and even
>
> <base_url>/entity/{id1}+{id2}+...
>
> In fact by treating the entityID as another "tag" the two URL patterns
> coincide and the only thing the consumer needs to do is to be able to
> handle multiple entities or empty results for all queries.
>
> <base_url>/entities/{id1}+{id2}+...
>
> and {id*} can be an entityID, an transformed entityID, a collections
> identifier or a "tag" and the semantics is that all have to match (AND)
>
> So we would wind up with a single URL pattern again...

Yes, I think this makes sense.

> 2. We might want to have a way to specify the signer. Lets say my
> MDX can handle multiple key-pairs each identified by an alias. We
> could stick this in the base_url so it doesn't really change anything
> but it might be good to spell this out in the spec...
>
> <base_url>/{signer}/... something...

I don't know, to me this doesn't feel like something that should be 
baked in anywhere.  I feel like it should be up to the software and 
deployer to figure out how to identify a particular bag of bits.  URLs 
might be one way, but there could be others (e.g. the client 
authenticates and the app has a mapping that determines which key to 
sign data with for that client).

-- 
Chad La Joie
http://itumi.biz
trusted identities, delivered