[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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> <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> 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> <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 ### > -----Original Message----- > From: Schleiff, Marty [mailto:marty.schleiff@boeing.com] > Sent: Wednesday, February 01, 2006 2:36 PM > To: 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? > > Ahhh - we misunderstood each other. Each metadata cross > reference has 3 parts, and your example has only two. (even > $d and $v have 3 parts, but the second part has a default if > it's left off). The metadata for public key would look > something like ($t*pk*<BASE64-encoded-public-key>). The 3 > part is the actual public key, which is whiy it could be long. > > I'm a directory person, so I don't think =sakimura/($t*pk) > should return anything; it's not a command, it's just an > identifier. Or, maybe XRI resolution could return a service > point for the directory service that holds this entry. I > think you would use LDAP, or some other protocol/query > language to lookup the public key, e.g., > > ldapsearch -h <directory-server> -p <port> -b > <search-base> -s <scope> "xri=\=sakimura" > > or > > > ldap://<directory-server>:<port>/<search-base>??<scope>?"xri=\ > =sakimura" > > (with appropriately escaped quotes, equals, and backSlashes) > > Note the these examples are out of my head, so they're not > completely accurate. The LDAP URL is defined in RFC 2255. > > Marty.Schleiff@boeing.com; CISSP > Associate Technical Fellow - Cyber Identity Specialist > Computing Security Infrastructure > (206) 679-5933 > > -----Original Message----- > From: Sakimura, Nat [mailto:n-sakimura@nri.co.jp] > Sent: Tuesday, January 31, 2006 5:26 PM > To: Schleiff, Marty; 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? > > Hi Marty, > > Thanks for the response. > > > Also, we could define a new $t type specifically for public keys. > > However, this could generate pretty long XRIs. > > I am not sure if it should be in the metadata spec or > community spec (in which case, GRS spec should have something > like that), but defining new $t type is definitely one way of > doing it. > > However, I did not get why this could generate long XRIs. > > Requesting > > =sakimura/($t*pk) > > should return a pointer to the public key of =sakimura, and > XRI itself does not look very long. > > Nat > > > -----Original Message----- > > From: Schleiff, Marty [mailto:marty.schleiff@boeing.com] > > Sent: Wednesday, February 01, 2006 1:14 AM > > To: 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? > > > > Hi Nat, > > > > In the Metadata Types spec we're defining something similar to what > > you describe. It's a metadata tag for HIT (a Host Identity > tag in the > > Host Identity Payload protocol - see > > http://www.irtf.org/charter?gtype=rg&group=hip). > > > > For example: ($t*hit*<hit-value>) > > > > <hit-value> is a hash of a public key. > > > > Also, we could define a new $t type specifically for public keys. > > However, this could generate pretty long XRIs. > > > > > > Marty.Schleiff@boeing.com; CISSP > > Associate Technical Fellow - Cyber Identity Specialist Computing > > Security Infrastructure > > (206) 679-5933 > > > > -----Original Message----- > > From: Sakimura, Nat [mailto:n-sakimura@nri.co.jp] > > Sent: Tuesday, January 31, 2006 2:26 AM > > To: xri@lists.oasis-open.org > > Subject: [xri] Question: Is there a standard way to compose an > > identifier for the public key of an object? > > > > Hi all, > > > > I have a question. > > > > Is there a standard way to compose an identifier for the > public key of > > > an object? > > > > For example, it would be very nice if I can be assured that > I will get > > > a public key for =bob by just doing > > =bob*(+public_key) or something. Then, without any prior knowledge > > about =bob, I can fetch his public key for bunch of processing. > > > > Cheers, > > > > Nat
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]