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

 


Help: OASIS Mailing Lists Help | MarkMail Help

xri message

[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?


Nat & Marty,

This is fascinating -- there are two approaches crossing here. This message
from Nat helps me understand that what he was asking for was a standard
"dictionary entry" for a public key, while what Marty was responding with
was a standard type definition for a public key expressed as an identifier.

The difference being that the former would retreive a public key as the
resource itself, while the latter would describe a public key as an
identifier.

For the former, an XRI cross-reference is IMHO ideal. In that case any of
the following would work fine.

	xri://=bob/(+public.key)
	xri://=bob*(+public.key)
	xri://=bob!(+public.key)

(See more about this below.)

For the latter, Marty was suggesting a way of describing a public key value
in an XRI itself. That would be something like...

	xri://=bob/($t*pk*xxxxxxsome-public-key-value-here-xxxxxxx)

...where Marty has a point that the full XRI that includes the public key
value might be rather long.

However, a cross-reference that contains metadata used to describe a public
key is not the same as the cross-reference that is intended to represent the
generic identity of a resource known as "public key". In other words...

	xri://=bob/($t*pk)

...would not be the address Bob's public key, but rather an incomplete
sentence saying, "Bob's public key is....". Whereas...

	xri://=bob/(+public.key)

...says, "This is the address of Bob's public key."

Now, what does it mean to resolve the latter, i.e., given that XRI, how
would you resolve Bob's public key?

One answer is that a combination of XRI resolution (of "xri://=bob") and
then selection of a service endpoint corresponding to the path
"(+public.key)" and then doing a GET on that service endpoint URI.
Presumably in this case the application doing the GET will make the request
using a media type that describes the format in which they wish to receive
the public key (text? html? xml?), and the server will respond accordingly.

A second answer is that, if the application knows of a specific data access
service by which the public key attribute may be requested, the application
requests resolution of "xri://=bob", specifies that data access service
type, receives back the service endpoint URI, and then does a GET on that
URI using the parameters of that data access service. 

In either case, the responding server/service needs to recognize the
identifier for the attribute being requested. A good solution to this is a
community dictionary, which is where an XRI such as "+public.key" would be
registered. If so, the service would know to accept a request for a local
resource called "+public.key" or "(+public.key)" and return a public key.

Does that answer your question, Nat?

=Drummond 

-----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
> 
> ---------------------------------------------------------------------
> 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 
> 
> 

---------------------------------------------------------------------
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_workgroups.php 




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