RE: [xri] Question: Is there a standard way to compose an identifier for the public key of an object?

["Sakimura, Nat" <n-sakimura@nri.co.jp>]

Hmmm.  This is where we need to have a better formatting client :-)

My responses below: 

> -----Original Message-----
> From: Drummond Reed [mailto:drummond.reed@cordance.net] 
> Sent: Sunday, February 05, 2006 10:40 AM
> To: 'Schleiff, Marty'; Sakimura, Nat; xri@lists.oasis-open.org
> Subject: RE: [xri] Question: Is there a standard way to 
> compose an identifier for the public key of an object?
> 
> The nesting is getting deep, but my responses to <MARTY> are 
> marked <DRUMMOND> below. (I also marked <NAT> for his messages.)
> 
> =Drummond 
> 
> -----Original Message-----
> From: Sakimura, Nat [mailto:n-sakimura@nri.co.jp]
> Sent: Thursday, February 02, 2006 4:49 PM
> To: Schleiff, Marty; xri@lists.oasis-open.org
> Cc: Drummond Reed
> Subject: RE: [xri] Question: Is there a standard way to 
> compose an identifier for the public key of an object?
> 
> <NAT>
> OK. As Drummond pointed out, we were talking about two 
> distinct things.
> The example: ($t*pk*<BASE64-encoded-public-key>)
> makes perfect sense to me, though I have a tendency to think 
> that XRI is just an identifier and is not data in most cases.  
> (The above example, the identifiier itself is a data. 
> XRI related data representation is what XDI talks about, I 
> think.) </NAT>
> 
> <DRUMMOND>
> I agree with your general sentiment, but when it comes right 
> down to it, all identifiers are a form of data insofar as 
> they are values of attributes of their parent contexts. XDI 
> itself illustrates this in that every XRI used to identify a 
> Resource or a Link is the value of an XRI element.
> </DRUMMOND>
<NAT>
I need to think this deeper, and catch up with XDI :-)
</NAT>
> 
> <MARTY>
> <BASE64-encoded-public-key> is just an identifier; it 
> identifiers the holder of the corresponding private key. It 
> happens to have some other interesting characteristics that 
> an application can recognize because of the metadata $t*pk. 
> Public key is quite interesting as an identifier, because it 
> is cryptographically bound to the appropriate individual - we 
> don't have to do any identifier mapping!
> </MARTY>

<NAT>
This is fascinating. This just did not occur to me. 
Indeed, public key should be very useful, though it may become 
very long. 

To make it more consice,  we could use md5 or sha1 hash 
of the public key as an identifier for the shorter version of it. 
</NAT>
> 
> <NAT>
> What I was talking about was a standard way to address the 
> public key of an identity/entity. It is illustrated in 
> Drummond's post that
> =sakimura/(+public.key) would be one way of doing it. 
> What I was suggesting was that it would be nice to have a 
> standard way to express such so that an application can fetch 
> the public key of an entity without other knowledge. 
> 
> For the resolution of it, the service end point may return 
> variouls protocol uris. LDAP is one way, but it could be 
> http/https/ftp/gopher/smtp/tftp etc. The resolution process 
> just returns the uri appropreate for the protocol of the 
> client application that points to the public key. 
> </NAT>
> 
> <DRUMMOND>
> Agreed, but isn't there one more step in this process, namely 
> specification of the format of the returned data? That's what 
> XDI is all about -- standardizing both the request format 
> (XRI syntax), the bootstrap dictionary (the XDI service 
> dictionary) and the response format (XDI documents).
> 
> The "slippery slope" that the XRI TC would be going down once 
> it moved into the data dictionary space would be specifying 
> both the service type for requesting the data identified by 
> the dictionary XRI and the data interchange format in which 
> it would be returned.
> 
> It seems like that might be closer to the province of the XDI 
> TC, but then, I might be biased ;-) </DRUMMOND>
> 
> <MARTY>
> I recognize that service points could be LDAP or any other 
> protocol; however, I'm a proponent of LDAP, so I tend to use 
> it in my examples. I haven't followed the resolution 
> discussions very closely, so maybe there are capabilities I 
> don't know about -- but the expectation that "The resolution 
> process just returns the uri appropriate for the protocol of 
> the client application..." seems too difficult for me. How 
> would the resolution process know which protocol(s) the 
> client can use?
> If the client somehow asks for an LDAP service point, what 
> should resolution do if the XRD only has http service point? 
> I think the processing of the XRD should be left to the client.
> </MARTY>

<NAT>
Neither have I been following closely enough on the resolution, 
but I have an impression that the choice will be made by the 
client from the list of URIs that XRD returns. 

Client being capable of expressing what transport type and 
media type it expects to the server so that the server can 
make the pre-selection is nice, but I do not know if such 
thing is in the spec. 
</NAT>
> 
> <DRUMMOND>
> Marty has a good point, and one that may fit with Nat's 
> original point. The XRI TC could indeed define an LDAP local 
> resolution service. The CD 01 Resolution spec mentioned 
> exactly that possibility.
> </DRUMMOND>
> 
> ### END INLINE RESPONSES ###
>