[mdx] what to trust

[Leif Johansson]

>
> I'm not sure whether the concept you want is "location" (where you
> happened to get the metadata from, say some URL) so much as let's say

Yes thats the idea.
> "origin" (where the metadata came from).  One difference is that I
> don't think we'd want to take much trust out of where you happened to
> get an aggregate from, given DNS vulnerabilities and a reluctance to
> get trust out of TLS.  Integrity of the channel shouldn't be important.

I think low trust could be placed in a proove-you-owned-the-domain-by-
returning-this-cookie scheme. 

>
> The way I think I'd look at it is that the signature is evidence
> you're using to bind the metadata you've received to a publisher and
> their practice statement, which works independently of the way the
> metadata gets from the publisher to you.

Well a metadata entry could come to you from two different sources
with two different signatures (one aggregate and one from the entity
itself for instance) so the trust is definitely a function of how you got
hold of the metadata even if (as Scott points out) you need to separate
concerns properly...

>
> One place that turns out to be a little wrinkled is the case of a
> publisher with multiple practice statements.  That's not common today,
> but what Josh is talking about may fall into this category and of
> course the case of a federation operator who wants to co-locate
> registration and publishing with different guarantees is similar.
>
> You could distinguish the practice statement associated with an
> aggregate by the key used for signing, if the publisher had many keys.
>
> Alternatively you might use the EntitiesDescriptor/@Name to
> distinguish: for example, we might publish
> @Name='http://ukfederation.org.uk ' to members under one practise statement
> and @Name='http://ukfederation.org.uk/registered' to other aggregators
> under a second practise statement.  This second idea doesn't work,

Yes but you'd use different keys for the two cases right so I think keeping
track of the key is probably best. That keeps us from having to keep track
of the envelope (which I think we said we didn't want to do).

> unfortunately, for single EntityDescriptor element documents as they don't
> have a "who says so" attribute separate from the @entityID.  I guess we
> could fix that by (in the new publishing protocol) always wrapping single
> entity documents in a separate
> EntitiesDescriptor, but that sounds pretty unpleasant too.
>
> 	-- Ian

so anyways I've been coding and I have a screenshot (cheers all round)
which shows me sending a location to it and pulling down the downloaded
metadata. The id is generated by a sha1 hash on the entire xml 
(canionicalized) since I don't think uniqueness of entityID implies uniqueness
of metadata (eg aggregators might add extensions).

	Cheers Leif
-------------- next part --------------
A non-text attachment was scrubbed...
Name: saml-md-manager.png
Type: image/png
Size: 204007 bytes
Desc: not available
URL: <http://lists.iay.org.uk/pipermail/mdx-iay.org.uk/attachments/20090506/dd6cb4ad/attachment-0002.png>