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] | [Elist Home]


Subject: RE: [xri] Top Ten XRI Requirements


I agree,

My two cents:

Related to access control. I was using SPKI for a while in the past and
they had the idea of using Pbkeys as the unique entity identifiers. (SDSI
allowed for local names, but they were always resolved to Pbk's). Access
control using this identifying schema was fairly straightforward. The
problem with that schema was key revocation --- which implied "identity"
revocation and thus "entity" revocation. 

Thus we need a requirement that explicitly states that:
"Authentication-method and Access control method-independence: the ability
for an identifier to identify a resource independent of the authentication
technologies used to authenticate it and the access control systems used
to manage it."


Xavier.

--
Xavier Serret.     Tel  +33 44236 4543
Corporate R&D Strategy @ Gemplus

-----Original Message-----
From: Drummond Reed [mailto:Drummond.Reed@onename.com]
Sent: Wednesday, February 05, 2003 5:41 PM
To: Sakimura, Nat; 'xri@lists.oasis-open.org'
Subject: RE: [xri] Top Ten XRI Requirements

Nat,

Very good point - these "Top 10" requirements are directed at the
addressing
syntax/resolution portions of the TC's charter and not the data exchange or
metadata features.

I strongly agree that access control and auditability are essential to the
data exchange requirements. Perhaps we should start a second "Top 10" list
for the data exchange and metadata features.

BTW, I should have explicitly mentioned internationalization under #4.

=Drummond

-----Original Message-----
From: Sakimura, Nat [mailto:n-sakimura@nri.co.jp]
Sent: Wednesday, February 05, 2003 12:56 AM
To: Drummond Reed; 'xri@lists.oasis-open.org'
Subject: RE: [xri] Top Ten XRI Requirements

Looks like these "Top" requirements are specifically for the
addressing aspect of XRI. I suppose there are other parts
to XRI. To me, one of the most important aspect of such protocols is
the access control. Without it, one cannot safely resolve and
share data. Thus, access control and traceability is one of the priorities.

I am going to send another requirement tomorrow.

By the way, is anyone on this list working on something like GCI
and IC Tag? We might need to look at these as well.
On similar note, Japanese government is also working on similar
code/messaging scheme that we may want to influence.

Nat

> -----Original Message-----
> From: Drummond Reed [mailto:Drummond.Reed@onename.com]
> Sent: Wednesday, February 05, 2003 4:29 AM
> To: 'xri@lists.oasis-open.org'
> Subject: [xri] Top Ten XRI Requirements
>
>
> All:
>
> In reviewing our strawman requirements document and Gabe's excellent
> motivations document, I found myself wanting to boil it down
> to a "top ten"
> list to help us focus on the essence, particularly as we
> approach the f2f.
>
> I publish the following as a first attempt at doing this, and
> also as a
> reminder to everyone of their homework assignment to send in
> to the list
> either: a) any open issues relative to the requirements
> proposed so far, or
> b) confirmation that you don't have any open issues.
>
> =Drummond
>
> TOP TEN REQUIREMENTS FOR XRIs
>
> 1) Location-independence: the ability for an identifier to identify a
> resource independent of its physical location on the network.
>
> 2) Application- and transport-independence: the ability for
> an identifier to
> identify a resource independent of the application or protocol used to
> access the resource.
>
> 3) Persistence: the ability for an identifier to permanently
> identity the
> same resource (i.e., not be reassigned).
>
> 4) Human and machine optimization: the ability for identifiers to be
> optimized for either human readability/memorability or
> machine and network
> efficiency.
>
> 5) Peer-to-peer: the ability for any resource to serve as its own root
> identifier authority (i.e., no centralized or absolute
> authority required).
>
> 6) Unlimited federation: the ability for identifier authority to be
> delegated to any depth.
>
> 7) Context addressability: the ability for a resource to be
> identified in
> the context of another resource.
>
> 8) Attribute addressability: the ability to identify the
> attributes of a
> resource to any depth.
>
> 9) Version addressability: the ability to identify the versions of a
> resource or its attributes to any depth.
>
> 10) Extensibility: the ability for the identifier scheme to
> be extended by
> adding new sub-schemes without changing the underlying architecture.
>



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


Powered by eList eXpress LLC