RE: Proposed disposition of Stuart Williams' comments on Metadata in URI 31

Hi Mark,

> Mark said: 
> Ok, but in those examples you gave, I don't believe the 
> information you talk about there is identifier metadata.  If 
> I read the second one correctly, you're claiming that 
> "reassignability" and "one-timeness"
> is identifier metadata, right?  If so, why?  And what breaks 
> if it was treated otherwise?  For example, what if, for the 
> second example, the assertion source sent the URI in a 
> message such as this one;
> 
>    <reassignable value="false">http://....</reassignable>

Just like I can use document metadata to help me decide how to treat a
document, I could use indicators of reassignability, one-timeness, the
meaning of query string parameters, or other characteristics to help me
decide how to treat an identifier. To me it seems like "reassignability"
and "one-timeness" are obviously identifier metadata -- I'd be
interested in hearing a few more people's views on this.

I can see some value in your example of including descriptive data (that
I call metadata) in the XML tags surrounding an identifier in an
assertion, because that might tell me how to deal with it when I receive
it. However, when I store the identifier for later reference and use
(like in a log file), unless I also store the descriptive data with it,
I lose visibility to the identifier characteristics. It would be better
to have them as part of the URI structure.

Your example gave me a couple new thoughts that aren't yet very well
developed - but here goes: Some of the descriptive data really consists
of minter claims about the identifier, as has been pointed out in
previous discussions about persistent identifiers. If such claims are
built right into the identifier, then it's obvious that the minter is
making such a claim. If such claims are made in XML tags like
<reassignable value="false">, then verification/nonrepudiation of the
claim would require some way to bind the claim to the identifier, such
as a digital signature on both the identifier and the claim. I
understand that an incoming SAML assertion or X.509 certificate would
indeed be signed, but I'd have to retain the whole assertion for
non-repudiation. I'd probably also have to retain every assertion
including that identifier, because different assertions might make
different claims about the identifier. This is lots bulkier than just
building it right into the identifier. 

Another thought: a SAML assertion authority, or an X.509 certificate
authority, is probably NOT the naming authority for the subjects of the
assertions/certs. Wouldn't you rather have claims about the identifier
be made by the naming authority rather than some other body?

Received on Friday, 29 September 2006 15:35:20 UTC