Subject: re re PIN

From: Terry Allen <[email-masked]>
Date: Fri, 26 May 2000 16:59:35 -0700

Michael wrote:
| On Fri, May 26, 2000 at 03:41:53PM -0700, Terry Allen wrote:
| > [using "mail" I don't seem to be able to respond to the list]
|
| as in /usr/bin/mail?

/bin/mail on my ISP, using Red Hat Linux.  The problem is that
Reply-To is set to the sender.  Never mind.

| > Stop me if I'm reading in something NSI doesn't intend.
|
| Nope. Your dead on so far...

although I may have mixed two points of view.  anyway ...

| > | The URN for our example: urn:pin:mm2136 names me personally...
| > |
| > | You use that URN in your system and you say, "Hey, I'm going to say
| > | that this URN has the human name of Michael Mealling". You can say
| > | that all day long. But unless you ask me via the PIN URN resolution
| > | service, you don't know if its true according to me or not. I may
| > | have changed my name.
| >
| > You're digging yourself a hole; now I want your document to say what
| > happens to the URN when Michael Mealling changes his name:  does it
| > apply to the same person, the same person throughout his life, the
| > same person only after the name change, or does it become deprecated?
|
| By the name I meant the name my parents gave me. Not the URN name. I.e.
| I.e. if I change my name from Michael Mealling to Michael Duncan (which
| is my fiance's last name) then that is also some piece of metadata
| associated with me that is obtainable via the metadata service which
| is accessed via the PIN URN resolution service. In this case, since
| URNs are for all time, you (the physical human being) have the URN
| forever (even beyond your lifetime).

That's what I had in mind, but it's specific set of info about you
(which may change, and that's key) that's named.

| > | You can assert all sorts of things about me in your database using
| > | that URN to uniquely and persistently talk about me. But its just
| > | _you_ talking _about_ me. You might be calling me names for all I know.
| >
| > But this is the use of URNs for designating, and these assertions are
| > no better or worse than NSI's.
|
| Correct.... Anyone can and should use the URN for designating something.
| But if they want to create some piece of metadata about it and have
| it be authoritative then they'd better ask the individual being named
| to make it available the authoritative metadata service...

That's where I mixed points of view.  I think, on reflection, that
what's named isn't (in this context) metadata, but data.  And you
need it to be, as I'll explain.

| > | The key here is that its you talking about me with no other authority
| > | than your just one of several billion people on the planet. Now,
| > | if you go through the PIN resolution service you are rest assured that
| > | the information there is what _I_ say it is. That's authoritative...
| >
| > So the URN names not you but your information about yourself as
| > supplied to NSI.
|
| Hmm... I think that's splitting a hair we don't intend on splitting.
| The URN names you the individual, we just supply an authoritative
| way of accessing your metadata via the network.

There is no single set of "my metadata".  What you want to say, I think,
given your business motive, is that the PIN URN is for information about
yourself *as supplied to NSI* (that gives you the hook you're looking
for), and, separately (probably not in the URN NID document), that as this
information is subject to change and URN resolution does not guard
against spoofing of resources, anyone wanting to use this URN for
very time-sensitive info, info that may be revised, or authentication,
probably wants to use NSI to resolve the URN.

That is, information that has no binding to a medium of dissemination
(such as a physical book) is obtained more reliably from the publisher
than from some other source (unless the obtainer has reason to trust
the other source just as much as he trusts the publisher).
...

| > | Yes. We are saying that our assertions are better than others since
| > | they are being made by the entity itself via our resolution service.
| > | I.e. our resolution service is acting as a proxy for me personally
| > | and since the URN is naming my electronix proxy, I am the one
| > | that is making those statements and thus they have more weight than
| > | yours.
| >
| > I think this is not a useful description ...
|
| I guess what I'm getting at, using your metadata registry verbage, is that
| the data in our metadata registry originated from the entity being named
| and not some third party. Thus it has more weight since its assertions
| come directly from the entity that originated that particular piece of
| metadata...

Well, no.  Equifax is a more reliable source of info about my credit
history than I am.  And using your "John Doe" example, which I elided,
the info in your registry isn't inherently reliable at all - you're
not in fact named John Doe.  That's why you need to argue from the
bases that the info may be revised and that the info *is that provided
to NSI* - otherwise I'd be able to get a PIN URN and then take it to
a competing service for use.  Or you need to argue that NSI owns the
URN itself.

| > | Yes we are. The URN names an electronic version of myself that I use
| > | to make authoritative assertions about myself....
| >
| > There is no electronic version of yourself.  There is the collection of
| > assertions.
|
| Hmm... Ok. How's this:
|
| Yes we are. The URN names a set of assertions about myself that I, by contract,
| assert as being the only source of assertions that you can trust as
| being authored by me.

Better, but not quite on; it isn't the only source of self-assertions,
and couldn't be - we make them all the time to various parties.  My
point is that it isn't the assignment of the URN that gives you a
business case, it's the servicing of the assertion set.  Your business
would work equally well with ANY URN if that URN were disseminated
with the information that the info is that provided to NSI and can
be obtained there most reliably.

| > Um, if NSI is not going to resolve URNs if the person related to them
| > doesn't continue to pay for, then it can have no objection if the
| > person arranges for some other resolution - unless it wants to assert
| > that it owns the URNs, which is fairly dangerous ground.  I do recall
| > we dealt with exactly this case (it was Ron's motorcycle poet).
|
| Yep. Since we assign them permanently (as a good URN namespace should),
| the owner can always decide to take it to some other resolver service.
| But if you follow the URN Resolution algorithm, find the authoritative
| server for that URN, and ask it about the URN it won't return anything.

There is no "authoritative server".  You mean "the NSI server that still
(falsely) claims to resolve that URN" or "claims that it resolves that
class of URNs but won't resolve this one", in which case it would be
interesting to know what error listed in RFC 2483 section 4.3 you'd
return.

| > | Yep. But its by a third party... The metadata behind a PIN URN is
| > | authoritative because it is a set of assertions I make about myself.
| >
| > That implies strongly that what is named is the set of assertions;
| > that is, NSI's I2C and I2R would return the same thing.  But another
| > registry's I2C might return something different (a rating of the
| > reliability of the URN, for example).
|
| Sure but if its via some other registry you won't be able to trust that
| the information in it was authored by the entity that the URN names.

Depends on how much I know about that registry and the entity, but
anyway, that's why you have to say that the info is that provided to
NSI (and assert that NSI doesn't get duped by its customers, ahem).
...

| I do like your verbage about the metadata registry. I'll definitly put
| that in the draft....

Thanks, but think about it as data in this context (metadata in some
other context).

regards, Terry

regards, Terry