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

["Wachob, Gabe" <gwachob@visa.com>]

This is all a wonderful discussion. 

But let me ask why we are having it. Do we ask "whats the standard way
to retrieve a user's public key" with respect to HTTP? If not, why not? 

One answer is that there is a general resistance to encoding too much in
identifiers. I won't go into that argument here - there are certainly
good arguments on both sides.

The anti-encode-it-in-the-identifier crowd would argue that what you
should really be doing is resolving the identifier for the user and then
getting some sort of description (cough, XRD, cough) that has a
*pointer* (a URI for the key whose relationship with the "user"
identifier is perhaps expressed in XML or RDF) to the key. You then
resolve that URI to actually get the key. 

Now, we tend to suggest to the community that it's a good practice to
stick in structured stuff into the identifier thus making the
"resolve-identify-resolve" pattern above seem to be extra work for no
benefit. Maybe so. But consider that this pattern is the prevalent mode
of discovery metadata about identified resources in the web - partially
because of sound architectural precepts, and partially because of some
of the mechanics of how the web is deployed (e.g. some users don't have
full control over "their" URLs and therefore don't have the flexibility
to add arbitrary stuff in "their" URL). 

Just wanted to make sure we have the bigger picture in mind for this
discussion (which is really a discussion we're likely to have over and
over again unless we address this systematically). 

    -Gabe

> -----Original Message-----
> From: Schleiff, Marty [mailto:marty.schleiff@boeing.com] 
> Sent: Monday, February 06, 2006 8:31 AM
> To: Tan, William; Drummond Reed; 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?
> 
> What happens if an individual has more than one certificate 
> (containing
> a public key) for a particular purpose? The individual could have a
> medium assurance certificate ofr encryption and a higher assurance
> certificate for encryption. Also, various signing certs from various
> issuers for various purposes. Today's certificate-aware 
> client software
> tends to display all the available certs for the individual, and then
> leave it to the individual to select which one to use. It's not very
> user friendly, but it's still left to the user, because it's also hard
> for software to make such a decision.
> 
> 
> Marty.Schleiff@boeing.com; CISSP
> Associate Technical Fellow - Cyber Identity Specialist
> Computing Security Infrastructure
> (206) 679-5933
> 
> -----Original Message-----
> From: Tan, William [mailto:William.Tan@neustar.biz] 
> Sent: Sunday, February 05, 2006 10:53 AM
> To: Drummond Reed; 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?
> 
> Nat's idea is an intriguing one. 
> 
> The standard way to retrieve the public key of an identity is probably
> best specified by a xrd_service_type value of "+public.key".
> 
> I can then publish my public key using a Service Type of 
> +public.key and
> the MediaType's would indicate the data formats in which the 
> public key
> may be represented. E.g. application/x-x509-ca-cert or
> application/pgp-keys.
> 
> What happens if we want to publish more than one public key? E.g. One
> for S/MIME and another for PGP. One way is to couple Path 
> selection with
> Service Type selection by publishing =Sakimura/(+public.key)/smime and
> =Sakimura/(+public.key)/pgp. This way, an application can easily list
> all the available public keys for the user to decide.
> 
> wil.
>  
> > <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>
> > 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  You may a link to this group and all 
> your TCs in OASIS
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgr
> oups.php 
> 
>