OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xdi message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [xdi] UUIDs in XDI


On Sun, Dec 15, 2013 at 11:18 PM, Markus Sabadello <markus.sabadello@xdi.org> wrote:

On Mon, Dec 16, 2013 at 5:18 AM, Drummond Reed <drummond.reed@xdi.org> wrote:
On Sun, Dec 15, 2013 at 8:51 AM, Markus Sabadello <markus.sabadello@xdi.org> wrote:
In XDI, we use UUIDs to generate Cloud Numbers, e.g.:
[=]!:uuid:06d1ef2b-5499-401a-ac88-89f637f83803
The ones we have registered so far in the Neustar OTE registry are all "type 4" UUIDs as specified by the RFC:

This means that 6 out of the 128 bits are constant, while all others are random.
The consequence is that the first bold character indicated above will always be 4.
And the second bold character indicated above will always be >= 8.

In order to map old I-Numbers to Cloud Numbers, we currently "double" them, e.g.:
[=]!:uuid:86128447-0cac-f315-8612-84470cacf315
This approach seems to violate the UUID RFC. As an alternative we could:

1. Use a "magic number" that is constant and identifies old I-Numbers, e.g:
[=]!:uuid:86128447-0cac-f315-1234-567890abcdef
2. With a "variant" of option 1, our UUIDs could actually have the constant 6 bits of "type 4" UUIDs:
[=]!:uuid:86128447-0cac-4321-fedc-f315ba987650
3. Or we could use some other information from the registry and encode it in the UUID, e.g. the I-Number's registration date:
[=]!:uuid:86128447-0cac-f315-2007-011312300000
4. Or we somehow add additional new, unrelated "type 4" Cloud Numbers to the registry that would live side by side with the old I-Numbers.

I believe only this last approach would be an "allowed" use of UUIDs with regard to the RFC.
But it would also mean an additional engineering task primarily on the Neustar side of things.
The other approaches all have the problem that they are either not fully random, or that they don't have the required constant 6 bits.

In any case, our requirements here are that the mapping between old I-Numbers and new Cloud Numbers must be
bidirectional and unambiguous, and that old I-Numbers in the registry do not change.

So, Markus, to net it out: what approach are you recommending for the XDI.org registry that will meet these two requirements? And do Animesh and Les agree? 

I would also be interested in Animesh' and Les' opinions, but my sense is that even though approach 4 would be the only fully correct one, I don't think we have the resources right now to do it. We would have to figure out how to get new Cloud Numbers into the registry, while also keeping the old i-Numbers intact, and then we'd have to make both resolvable, have both in the XRDS, etc. I don't think we can do that right now, so I'd say we stick with the "doubling" approach for now even though it doesn't produce RFC-conformant UUIDs.

I tend to agree. Animesh and Les, please do weigh in.

 
 

---------------------------------

Another place in XDI where we are not using UUIDs right now, but where we could use them, is for members of a collection in certain situations.

For example, in XDI Discovery we currently represent a collection of URIs as follows:

([=]!:uuid:0707f2ff-4266-9f14-0707-f2ff42669f14)[<$uri>]<!:sha512:8d79603ea32d8a44f9d4938471aa7c2c61351b6121ec46754d9df5778065b1358e693d4ef89badaf507929a40c25001a65c333a01ea06dc9d61daa163e61c30b>&/&/"http://mycloud.neustar.biz:14440/users/%5B%3D%5D%21%3Auuid%3A0707f2ff-4266-9f14-0707-f2ff42669f14"

Here, the member identifier (the long SHA-512 value) is derived from the literal value.
I was planning to do something similar for storing verified phone numbers and e-mail addresses in the Respect Network Member Graph.

Instead of doing that, we could use "type 3" or "type 5" UUIDs, which are also derived from the hash of a string.

But I think in this case the way we are currently doing it is just fine.

Two questions:
  1. Wouldn't using a UUID to identify the value as a member of the collection be much shorter than a SHA-512 value? 
Yes, because it would be based on MD5 or SHA-1 rather than SHA-512, which would also be just fine.

Cool. 
  1. Don't you want the member ID to be independent of the value, i.e., so that it doesn't change when the value changes? If so, why not just generate a UUID according to the strongest algorithm in the UUID RFC and use that?
Because the XDI Discovery Service doesn't have any state, so if it generates UUIDs, they would be different with every XDI discovery request. I can't store them in the XRDS service endpoints. In fact, the XRDS service endpoints don't have any identifiers at all, so in order to turn them into XDI member IDs, the value itself is really all I have as a basis. Furthermore, in an XRDS service endpoint, the value can't really "change", you can only remove one and add a new one.

Hmmm. That seems like one of the places that the old XRDS architecture and the new XDI architecture diverge. But this seems like a discussion that should probably be taken up by XDI.org and not on the OASIS XDI TC list, since this list is about the XDI standard and not a particular implementation community.

=Drummond 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]