One document matched: draft-otani-ccard-00.txt
Capability Card Koji Otani
INTERNET DRAFT Hiroyasu Sugano
Madoka Mitsuoka
Fujitsu Laboratories, Ltd.
Expires: May 1999 18 Nov. 1998
Capability Card: An Attribute Certificate in XML
<draft-otani-ccard-00.txt>
Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." To view
the entire list of current Internet-Drafts, please check the "1id-
abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or
ftp.isi.edu (US West Coast).
Copyright Notice
Copyright (C) The Internet Society (1998). All Rights Reserved.
Abstract
This document describes basic ideas and data components of
'Capability Card,' which is a kind of attribute certificates designed
from the standpoint of a secure communication framework on the
Internet. Similar to the SPKI certificates, a capability card can be
used to grant a person particular access privileges to resources like
WWW pages, IRC channels, and message boxes. In addition, it can
carry a variety of descriptive information about the issuer, the
resources, and the privileges specified in it. A capability card is
written in XML, which is becoming a standard format rapidly for the
internet data exchange. Consequently, users can handle various
information in capability cards visually with an XML viewer. This is
a fairly desirable feature for the existing internet services.
In this document, following the motivation and the basic concepts,
the elements of XML DTD of capability cards are described.
Otani/Sugano/Mitsuoka [Page 1]
INTERNET DRAFT Capability Card 18 Nov 1998
Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" are to be interpreted as described in RFC 2119.
Otani/Sugano/Mitsuoka [Page 2]
INTERNET DRAFT Capability Card 18 Nov 1998
Table of Contents
1. Introduction ......................................... 4
1.1. Backgrounds and Motivation ........................... 4
1.2. Capability Cards ..................................... 4
1.3. Glossary ............................................. 5
1.3.1. Capability ........................................... 5
1.3.2. Issuer ............................................... 5
1.3.3. Subject .............................................. 5
1.3.4. Holder ............................................... 5
1.3.5. Identity Authentication .............................. 5
1.3.6. Holder Authentication ................................ 6
1.3.7. Verifier ............................................. 6
2. Overview of Capability Cards ......................... 6
2.1. Attribute Certificates for Access Privileges ......... 6
2.2. Communication Instruments ............................ 6
2.3. XML .................................................. 7
2.4. Delegation and Its Control ........................... 7
2.5. Anonymous Subjects ................................... 7
2.6. Unsigned Cards ....................................... 8
3. Capability Card Data Elements ........................ 8
3.1. capability-card element .............................. 8
3.1.1. signature element .................................... 8
3.2. contents element ..................................... 9
3.3. descriptive information .............................. 9
3.3.1. short-text ........................................... 10
3.3.2. long-text ............................................ 10
3.3.3. image ................................................ 10
3.3.4. vcard-info ........................................... 10
3.4. capability element ................................... 10
3.4.1. target element ....................................... 11
3.4.2. verifier element ..................................... 12
3.4.3. access-right element ................................. 12
3.4.4. access-param element ................................. 12
3.4.5. description element .................................. 13
3.5. card-info element .................................... 13
3.6. issuer element ....................................... 13
3.6.1. user-info element .................................... 14
3.6.2. pk-certificate element ............................... 14
3.7. subject element ...................................... 15
3.7.1. user-info element .................................... 15
3.7.2. pk-certificate element ............................... 15
3.8. delegation element ................................... 16
4. Security considerations .............................. 17
5. Document Type Definition ............................. 18
6. Examples ............................................. 20
7. References ........................................... 25
8. Authors' Address ..................................... 25
Otani/Sugano/Mitsuoka [Page 3]
INTERNET DRAFT Capability Card 18 Nov 1998
1. Introduction
1.1. Backgrounds and Motivation
Secure authorization is one of the most important issues related to
actual services on the Internet. Various internet services, includ-
ing e-commerce, information sharing, and end-user communications,
have different authorization requirements based on their own prob-
lems;
- Should I give 5% discount to this customer?
- Should I allow this person to read that document?
- Should I accept this chat request from that person?
The SPKI group provides one solution to these problems based on pub-
lic key technology[SPKI]. SPKI certificates are attribute certifi-
cates which allow the designated key holders to have the specified
access privileges. As SPKI certificates are designed to be generic,
it seems to be applicable to a variety of services on the Internet.
On the other hand, privacy protection and handling of undesirable
messages have been matters of primary concerns of end-users for
recent years. Such issues would become more serious when more con-
venient messaging systems, like the instant messaging, prevail. We
consider that the notion of attribute certificates will be applicable
to solve the problems stated above. Suppose that a user could give
another person the access privileges to herself in a certificate and
the messaging server has incorporated a facility of access control
based on such a certificate. Then, she would be able to preclude
annoying messages from the parties without any certificates. More-
over, she would be able to revoke the certificates she had issued to
a party, which is no more trustworthy.
1.2. Capability Cards
Based on the above motivation, we have been developing a secure com-
munication framework using attribute certificates. We did not adopt
the SPKI certificate for the following reasons. In a communication
framework, users and service sites sometimes need extensible certifi-
cates which allow to convey various descriptive information of
several types, such as text, image data, or audio data. Some WWW com-
merce sites may issue the customers a number of customer cards, which
are certificates enclosing personalized information for each custo-
mer. And, still using the same data format, they may not need to sign
the data in some cases. Therefore, a data format suitable for such
(possible) certificates should be fully extensible.
"Capability Cards" are attribute certificates designed for such a new
communication framework. A capability card contains some access
Otani/Sugano/Mitsuoka [Page 4]
INTERNET DRAFT Capability Card 18 Nov 1998
privileges (or capabilities) to the designated resources. Usually, it
is digitally signed by an entity who has a responsibility for the
specified resources, such as WWW pages and message boxes, and issued
to another entity. The recipient can use it to access the issuer's
WWW pages or to send messages to her.
Moreover, a capability card can carry extra information about the
issuer, the resources and the privileges, to help its current holder
to know who the issuer is and what the holder can do with it. In this
sense, a capability card can be used like a vCard[VCARD], an elec-
tronic business card standard. Some capability cards can be
transferred to others to delegate the specified privileges to them.
This is sometimes desirable in intranets and some internet services
like community sites.
1.3. Glossary
In this document, some terms are used in the following meanings.
1.3.1. Capability
The capability in a capability card is a privilege to access the
specified resource. The capability is granted to the subject.
1.3.2. Issuer
The issuer of a capability card is the entity who has specified its
contents, and usually has signed it.
1.3.3. Subject
The subject of a capability card is the entity who has a privilege to
use the capability card. The subject is usually specified by the key,
or other identity the relevant service accept. But it can be
"anonymous" in some cases.
1.3.4. Holder
The holder of a capability card is the entity who currently holds it.
The holder can use the card if she/he is the same entity as the
specified subject or the subject is anonymous.
1.3.5. Identity Authentication
The identity authentication is the authentication which verifies the
correspondence of an entity and an actual person.
Otani/Sugano/Mitsuoka [Page 5]
INTERNET DRAFT Capability Card 18 Nov 1998
1.3.6. Holder Authentication
The identity authentication is the authentication which verifies that
an entity is the subject of the card.
1.3.7. Verifier
The verifier is the entity which verifies the validity of capability
cards. It may be an application server or a separate server related
with the application.
2. Overview of Capability Cards
2.1. Attribute Certificates for Access Privileges
A capability card is a kind of attribute certificates designed for a
new communication framework on the Internet. An entity issues a
capability card to another entity, usually specifying the subjects,
the resources, and the access privileges (or capabilities) to them,
and the validity period, signing with her digital signature. A capa-
bility card can convey multiple capabilities for the several
resources. The issuer should have a responsibility for the specified
resources in general. This responsibility relation will be verified
at the time of the use.
On the use of a capability card, the holder of the card firstly sends
it to the verifier. At that time, the holder usually should be able
to select one capability through a client's user interface. Then the
verifier practices the holder authentication unless the subject is
anonymous, and checks the validity of the use of the card. After the
verification is completed successfully, the authorization information
should be handed over to the resource by some means. The methods how
the holder authentication is practiced and how the connection between
the verifier and the application is established are not covered by
this document.
2.2. Communication Instruments
In addition to items necessary for the attribute certificate, a capa-
bility card can convey some descriptive information about the items.
For instance, it can include directory-style information about the
issuer or the subject, similar to the entries listed in vCard elec-
tronic business card standards. It can also have the explanations on
what the resources are and what privileges the holder will have. The
issuer can include various information on the specified items, like
image data, short text description, and long text description.
Otani/Sugano/Mitsuoka [Page 6]
INTERNET DRAFT Capability Card 18 Nov 1998
One of the intended usage of such capability cards is for message
cards with access privileges to some human-related resources, like
users' home pages, service sites' reception pages, IRC channels, and
contact points for instant messaging or IP telephony. This is a
fairly desirable feature in internet services like commerce and com-
munity sites.
2.3. XML
Capability cards adopt XML (eXtensible Markup Language)[XML] as a
syntactic framework of the data expression. Because XML is becoming
rapidly recognized as a standard format for the internet data
exchange, this adoption would make capability cards widely usable
with various application softwares. For example, capability cards can
be handled with an XML viewer to display images as the electronic
business cards.
Furthermore, XML is easily extensible to contain some extra data
fields, thus this is convenient for individual service sites, which
may sometimes need to put service-specific information into capabil-
ity cards.
2.4. Delegation and Its Control
One can transfer a capability card to other entities to delegate the
capabilities to them. The unit of delegation is not a capability,
but a capability card itself. Thus, in the case that a capability
card contains multiple capabilities, all the capabilities are
delegated at the same time. To delegate a capability card, one issues
a new card including the old one. The new card is said to be
"derived" from the old one.
To control delegation of capability cards, the issuers can specify
some parameters on delegation control; "depth," "propagate," and
"width." "Depth" takes an integer which is the limit of the depth of
delegation. "Propagate" takes a boolean, where false means the dele-
gator loose all the privileges in the card and true means the delega-
tor still possesses those privileges. "Width" takes an integer which
is the limit of the width of delegation. The delegation control with
these parameters may not be strictly performed. But the verifier
SHOULD be able to follow the use of the delegated cards, and to
detect an improper usage by verifying these parameters.
2.5. Anonymous Subjects
Otani/Sugano/Mitsuoka [Page 7]
INTERNET DRAFT Capability Card 18 Nov 1998
Although one usually issues a capability card specifying the subject,
a capability card can be issued with the subject "anonymous" as well.
When a capability card holder uses the card in general, the holder
authentication must be fulfilled. But, in the case of anonymous sub-
ject, the holder authentication is not necessary.
Capability cards with anonymous subject may be useful to propagate
the privileges to unknown masses. This is sometimes preferable when
some sites advertise their services for unknown users including the
privilege to access the WWW pages under some limitation.
2.6. Unsigned Cards
In some cases, a capability card may not be digitally signed. If an
issuer wants to issue a capability card only for the use of non
security-critical services, or just for informative use, digital sig-
nature may not be necessary. Thus, our framework allows a capability
card to be issued without digital signatures.
3. Capability Card Data Elements
As capability cards are written in XML (eXtensible Markup Language)
[XML], the syntax is conformable to the XML syntax. XML elements for
capability cards are described in XML DTD (Document type definition)
here. We will adopt the XML namespace when the namespace specifica-
tion is fixed in the near future.
3.1. capability-card element
<!ELEMENT capability-card (
contents, <!-- card body -->
signature? <!-- digital signature -->
) >
The "capability-card" element is the root element of the capability
card. The "capability-card" element MUST contain a "contents" element
and MAY contain a "signature" element. The "contents" element is
described later. The "signature" element is defined as follows.
3.1.1. signature element
<!ELEMENT signature (#PCDATA)>
<!ATTLIST signature
algorithm CDATA "md5WithRSAEncryption" <!-- name
Otani/Sugano/Mitsuoka [Page 8]
INTERNET DRAFT Capability Card 18 Nov 1998
of signature algorithm -->
>
The content of the "signature" element is the issuer's digital signa-
ture. This element has the "algorithm" attribute which specifies the
name of the algorithm of digital signature.
3.2. contents element
<!ELEMENT contents (
(capability-card <!-- other capability card -->
| capability* ), <!-- capability list -->
card-info, <!-- card information -->
issuer, <!-- issuer's information -->
subject, <!-- subject's information -->
delegation <!-- delegation parameters -->
) >
The "contents" element is the body of capability cards. It consists
of the elements listed above.
3.3. descriptive information
Some of the elements described later can have descriptive information
for the convenience of users and service sites. For the sake of
facility of element definitions, the entity for descriptive informai-
ton is defined here.
<!ENTITY % desc "
short-text?, <!-- short description in text -->
long-text?, <!-- long description in text -->
image?, <!-- descriptive image -->
vcard-info?, <!-- vCard -- >
" >
The contents of these elements will be utilized in the following
cases.
(1) Each capability card can have its own visual representation.
This helps users manage a number of capability cards and pick
one up among them.
(2) A tool handling capability cards will be able to display the
information about capabilities in the cards. This helps users
select a capability to use among them.
(3) Service sites can get the user's information.
Otani/Sugano/Mitsuoka [Page 9]
INTERNET DRAFT Capability Card 18 Nov 1998
(4) Users can get other's information such as a telephone
number.
3.3.1. short-text
<!ELEMENT short-text (#PCDATA) >
This is a short description in text for the title of icon or the menu
item, etc.
3.3.2. long-text
<!ELEMENT long-text (#PCDATA) >
This is a long description in text.
3.3.3. image
<!ELEMENT image (#PCDATA) >
<!ATTLIST image
format CDATA "jpeg" <!-- name of an image format -->
>
The content of this element is an image which may be used as an icon.
The image MUST be base64 encoded. The "format" attribute specifies
the name of data format of the image, and the default is "jpeg."
3.3.4. vcard-info
<!ELEMENT vcard-info (
vCard? <!-- vCard in XML -->
) >
<!ATTLIST vcard-info
href CDATA #IMPLIED <!-- link to vCard -->
>
This is a vCard data in XML[vcard-xml]. The "href" attribute, whose
value is URL, MAY be used to point to the vCard data. In that case,
the content MAY be omitted.
3.4. capability element
A capability card MAY contain zero or more "capability" elements. The
Otani/Sugano/Mitsuoka [Page 10]
INTERNET DRAFT Capability Card 18 Nov 1998
"capability" element specifies the resource and the privileges to be
granted to the subject.
<!ELEMENT capability (
target, <!-- information about the target resource -->
verifier?, <!-- information about the verifier -->
access-right, <!-- access rights -->
access-param?, <!-- parameters handed over upon access -->
description?, <!-- descriptive information about
this capability -->
) >
<!ATTLIST capability
times-to-use CDATA "0" <!-- how many times this capability
can be used -->
not-before CDATA #IMPLIED <!-- the beginning date of validity period -->
not-after CDATA #IMPLIED <!-- the ending date of validity period -->
>
Meanings of the attributes are given as follows.
(1) times-to-use attribute
This attribute specifies the maximum number of times this capa-
bility can be used. The value is an integer. If the value is
less than or equal to 0, the capability can be used without
limit. This attribute is optional. When this is omitted, the
default value is 0. A verifier SHOULD be able to count the
number of the use of each capability card and to check whether
the number does not exceed the value of this attribute.
(2) not-before attribute
This attribute specifies the date/time when this capability
becomes valid. The date/time MUST be specified in UTC time and
the form is "YYYY-MM-DDTHH:MM:SSZ". This attribute is optional.
If this is omitted, this capability is valid since its creation
time.
(3) not-after attribute
This attribute specifies the date/time when this capability
becomes invalid. The date/time MUST be specified in UTC time
and the form is "YYYY-MM-DDTHH:MM:SSZ". This attribute is
optional. If this is omitted, the validity of this capability
does not expire.
3.4.1. target element
Otani/Sugano/Mitsuoka [Page 11]
INTERNET DRAFT Capability Card 18 Nov 1998
<!ELEMENT target (%desc;) >
<!ATTLIST target
uri CDATA #REQUIRE <!-- URI of the target resource -->
>
This element contains information about the resource to which this
capability may be applicable. The "uri" attribute is a URI of the
target resource. The "uri" attribute MUST be specified. The content
of this element is descriptive information about the target resource.
3.4.2. verifier element
<!ELEMENT verifier (%desc;) >
<!ATTLIST verifier
uri CDATA #REQUIRE <!-- URI of the verifier -->
>
This element contains information about the verifier that verifies
this capability. The "uri" attribute is a URI of the verifier. The
content of this element is descriptive information about the verif-
ier. This element is optional. If this is omitted, the value of the
target element MAY be used.
3.4.3. access-right element
<!ELEMENT access-right (%desc;) >
<!ATTLIST access-right
label CDATA #REQUIRE <!-- list of access right labels -->
>
This element specifies the access rights for the target resource to
be granted to the subject. The content of this element is descriptive
information on the access rights.
Access rights are specified by a list of labels in the "label" attri-
bute. A label is a name which represents a collection of access
rights. The vocabulary for labels and access rights depends on the
target resource. The mapping of a label to a collection of access
rights is defined by an access control policy specified for the
access control mechanism of the applications.
3.4.4. access-param element
<!ELEMENT access-param (ANY) >
Otani/Sugano/Mitsuoka [Page 12]
INTERNET DRAFT Capability Card 18 Nov 1998
This element specifies some parameters which are handed over to the
application when the card is used to access the target resource. This
element is optional.
3.4.5. description element
<!ELEMENT description (%desc;) >
This element contains descriptive information about this capability
itself.
3.5. card-info element
The "card-info" element contains information about the capability
card itself.
<!ELEMENT card-info (%desc;) >
<!ATTLIST card-info
card-id CDATA #REQUIRED <!-- this card's unique ID -->
issued-date CDATA #REQUIRED <!-- issued date -->
>
The content of this element is descriptive information about this
card. Meanings of the attributes are given as follows.
(1) card-id attribute
This attribute is the card ID. The card ID SHOULD be globally
unique.
(2) issued-date attribute
This attribute is the issued date. This MUST be specified as
UTC time. The form is "YYYY-MM-DDTHH:MM:SSZ".
3.6. issuer element
This element contains information about the issuer of the card.
<!ELEMENT issuer (
user-info, <!-- issuer's information -->
pk-certificate? <!-- issuer's public key certificate-->
) >
Otani/Sugano/Mitsuoka [Page 13]
INTERNET DRAFT Capability Card 18 Nov 1998
A capability card MUST have information enough for a verifier to
specify the issuer. In particular, a signed capability card MUST
have information to get the issuer's public key.
3.6.1. user-info element
<!ELEMENT user-info (%desc;) >
<!ATTLIST user-info
user-id CDATA #REQUIRED <!-- issuer's ID -->
>
This element contains the issuer's information except the public key.
The content of this element is descriptive information about the
issuer.
The "user-id" attribute specifies the issuer's ID by which the verif-
ier can specify the issuer. If the card is not a derived one, it is
usually the case that the issuer is a registered user at a service
which provides the resource specified in the card. In this case, the
registered ID is specified in this attribute. If this card is derive
from any other card, a URI form can be used.
3.6.2. pk-certificate element
<!ELEMENT pk-certificate (#PCDATA) >
<!ATTLIST pk-certificate
name CDATA #IMPLIED <!-- location where to get
public key certificate -->
>
This element specifies the issuer's public key (X.509) certificate or
the location to get the one. When the certificate itself is speci-
fied, it is embedded in the content in a base64-encoded form. In the
other case, the "name" attribute is used to designate the location
where the issuer's certificate resides. A typical value of this
attribute is an LDAP URL. If the "name" attribute is specified, the
content SHOULD be empty.
If the verifier can get the public key through the "user-id" attri-
bute of the "user-info" element, this element may be omitted.
For the purpose of the usage of capability cards, only a public key
is needed rather than public key certificates. But, X.509 public key
certificates is getting popular recently, thus we adopted them for
the interoperability with PKIX. Our framework does not force the cer-
tificate to be registered at a CA (Certificate Authority), however.
Otani/Sugano/Mitsuoka [Page 14]
INTERNET DRAFT Capability Card 18 Nov 1998
3.7. subject element
This element contains information about the subject of the card.
<!ELEMENT subject (
user-info, <!-- subject's information -->
pk-certificate? <!-- subject's public key certificate -->
) >
This element specifies the legal users of this capability card, but
it can be anonymous when no restriction on its users is needed. For a
capability card with the anonymous subject, any holder of it have the
specified capabilities. Otherwise, this element MUST provide enough
information to determine the subject.
3.7.1. user-info element
<!ELEMENT info (%desc;) >
<!ATTLIST user-info
user-id CDATA #REQUIRED <!-- subject's ID -->
>
This element contains the subject's information other than the public
key. The content of this element is descriptive information about the
subject.
The "user-id" attribute specifies the subject's user ID. If the sub-
ject is a registered user at a service which provides the resource
specified in the card, the registered user ID can be contained in
this attribute. Otherwise, any ID of a URI form, except for
"anonymous", can be used. The value "anonymous" is reserved for the
case of the anonymous subject.
3.7.2. pk-certificate element
<!ELEMENT pk-certificate (#PCDATA) >
<!ATTLIST pk-certificate
name CDATA #IMPLIED <!-- location where to get
public key certificate -->
>
This element specifies the subject's public key (X.509) certificate
or the location to get the one. When the certificate itself is
specified, it is embedded in the content in a base64-encoded form.
In the other case, the "name" attribute is used to designate the
location where the subject's certificate resides. A typical value of
Otani/Sugano/Mitsuoka [Page 15]
INTERNET DRAFT Capability Card 18 Nov 1998
this attribute is an LDAP URL. If the "name" attribute is specified,
the content SHOULD be empty.
If the verifier can get the public key through the "user-id" attri-
bute of the "user-info" element, this element may be omitted.
For the purpose of the usage of capability cards, only a public key
is needed rather than public key certificates. But, X.509 public key
certificates is getting popular recently, thus we adopted them for
the interoperability with PKIX. Our framework does not force the cer-
tificate to be registered at a CA (Certificate Authority), however.
3.8. delegation element
<!ELEMENT delegation EMPTY>
<!ATTLIST delegation
depth CDATA "0" <!-- maximum number of depth
of delegation tree -->
propagate (true | false) "false" <!-- propagate or not -->
width CDATA "0" <!-- maximum number of width
of delegation tree -->
>
This element specifies the delegation parameters. Three attributes
can be specified and they have the following meanings.
(1) depth attribute
This attribute is the maximum number of the depth of delegation.
The value is an integer. If -1 is specified, the depth of dele-
gation is unlimited. If 0 is specified, one cannot issue a new
card derived from this card. The default value is 0. If this
card is derived from another card, the value of this attribute
SHALL be less than the value of the original card.
(2) propagate attribute
This attribute specifies whether or not the capabilities in this
card can be propagated to other entities. In other words, it
specifies the card to be self-reproducing or not. If this value
is "true", the delegator can still have the capabilities after
the delegation. If it is "false", one cannot use the capabili-
ties any more after the delegation. The default value is
"false". If the value of "depth" attribute is 0, this attribute
MUST be ignored. If this card is derived from another card and
the value of this attribute of the original one is "false", the
Otani/Sugano/Mitsuoka [Page 16]
INTERNET DRAFT Capability Card 18 Nov 1998
value of this attribute SHALL NOT be "true".
Because the verifier cannot check the original card which has
the false "propagate" value until the delegated one is verified,
it is RECOMMENDED that the client program is to obey this attri-
bute.
(3) width attribute
This attribute is the maximum number of the width of delegation
tree, that is, the number of cards which can be directly derived
from this card. The value is an integer. If 0 is specified, one
cannot derive a new card from this. If -1 is specified, one can
derive a new card without limit. This attribute is optional. If
this is omitted, the default value is 0. If the value of "depth"
attribute is 0 or the value of "propagate" attribute is "false",
this attribute MUST be ignored. If this card is derived from
another, the value of this attribute SHALL be less than or equal
to the value of the original one.
The verifier need not check this attribute literally. But, it is
RECOMMENDED that the verifier counts the number of the use of
the card directly derived from this one, and checks the number
does not exceed this value.
4. Security considerations
When one uses a capability card, the identity authentication is not
mandatory. If it is needed, one can do it through a mechanism such as
SSL(Secure Sockets layer)/TLS(Transport Layer Security).
However, on the use of a capability card, the holder authentication
is needed if the subject is not "anonymous." If the subject is
specified by the public key, it is expected that the authentication
is done through challenge-and-response using the key pair.
When the issuer gives a capability card to the subject, the identity
authentication may be needed. One can do it through a face-to-face
method, SSL, or etc.
Specifying these actual methods is beyond the purpose of this docu-
ment.
Since a capability card has neither the verifier's digital signature
nor the service's digital signature, the issuer only assures that the
card contains the specified capabilities.
Otani/Sugano/Mitsuoka [Page 17]
INTERNET DRAFT Capability Card 18 Nov 1998
Since descriptive information in a capability card is not assured by
any authority, the information could not be used in a critical appli-
cation.
5. Document Type Definition
The XML DTD for capability cards is as follows.
<?xml version="1.0" encoding="UTF-8"? >
<!DOCTYPE capability-card [
<!ENTITY % desc "
short-text?, <!-- short description in text -->
long-text?, <!-- long description in text -->
image?, <!-- descriptive image -->
vcard-info?, <!-- vCard -- >
" >
<!ELEMENT short-text (#PCDATA) >
<!ELEMENT long-text (#PCDATA) >
<!ELEMENT image (#PCDATA) >
<!ATTLIST image
format CDATA "jpeg" <!-- image format name -->
>
<!ELEMENT vcard-info (
vCard? <!-- vCard in XML -->
) >
<!ATTLIST vcard-info
href CDATA #IMPLIED <!-- link to vCard -->
>
<!ELEMENT capability-card (
contents, <!-- Card body -->
signature? <!-- Digital Signature -->
) >
<!ELEMENT signature (#PCDATA)>
<!ATTLIST signature
algorithm CDATA "md5WithRSAEncryption" <!-- name
of signature algorithm -->
>
<!ELEMENT contents (
(capability-card <!-- other capability card -->
| capability* ), <!-- capability list -->
card-info, <!-- card information -->
issuer, <!-- issuer's information -->
subject, <!-- subject's information -->
Otani/Sugano/Mitsuoka [Page 18]
INTERNET DRAFT Capability Card 18 Nov 1998
delegation <!-- delegation parameters -->
) >
<!ELEMENT capability (
target, <!-- information about the target resource -->
verifier?, <!-- information about the verifier -->
access-right, <!-- access rights -->
access-param?, <!-- parameters handed over upon access -->
description?, <!-- descriptive information about
this capability -->
) >
<!ATTLIST capability
times-to-use CDATA "0" <!-- how many times this capability
can be used -->
not-before CDATA #IMPLIED <!-- the beginning date of validity period -->
not-after CDATA #IMPLIED <!-- the ending date of validity period -->
>
<!ELEMENT target (%desc;) >
<!ATTLIST target
uri CDATA #REQUIRE <!-- URI of the target resource -->
>
<!ELEMENT verifier (%desc;) >
<!ATTLIST verifier
uri CDATA #REQUIRE <!-- URI of the verifier -->
>
<!ELEMENT access-right (%desc;) >
<!ATTLIST access-right
label CDATA #REQUIRE <!-- list of access right labels -->
>
<!ELEMENT access-param (ANY) >
<!ELEMENT description (%desc;) >
<!ELEMENT card-info (%desc;) >
<!ATTLIST card-info
card-id CDATA #REQUIRED <!-- this card's unique ID -->
issued-date CDATA #REQUIRED <!-- issued date -->
>
<!ELEMENT issuer (
user-info, <!-- issuer's information -->
pk-certificate? <!-- issuer's public key certificate -->
) >
Otani/Sugano/Mitsuoka [Page 19]
INTERNET DRAFT Capability Card 18 Nov 1998
<!ELEMENT subject (
user-info, <!-- subject's information -->
pk-certificate? <!-- subject's public key certificate -->
) >
<!ELEMENT user-info (%desc;) >
<!ATTLIST user-info
user-id CDATA #REQUIRED <!-- entity's ID -->
>
<!ELEMENT pk-certificate (#PCDATA) >
<!ATTLIST pk-certificate
name CDATA #IMPLIED <!-- location where to get
public key certificate -->
>
<!ELEMENT delegation EMPTY>
<!ATTLIST delegation
depth CDATA "0" <!-- maximum number of depth
of delegation tree -->
propagate (true | false) "false" <!-- propagate or not -->
width CDATA "0" <!-- maximum number of width
of delegation tree -->
>
] >
6. Examples
[Example 1]
This is a capability card which Sugano issued to Otani. The subject
is Otani, and the privileges are that he can access to get Sugano's
schedule and he can open a chat channel with Sugano by "project-
partner"'s rights. These privileges are specified in "capability"
elements. Since this card has a vCard element, a user agent can
display Sugano's name, the address and the telephone number of his
office. Using a capability-card enabled user agent, Otani can launch
a chat client program by selecting the displayed menu item "Chat to
Sugano," which is specified in the "description" of the "capability"
element. Since the value of "depth" attribute of "delegation" element
is 1, Otani can delegate the capabilities to others.
<?xml version="1.0" encoding="UTF-8"?>
<capability-card>
<contents>
<capability
Otani/Sugano/Mitsuoka [Page 20]
INTERNET DRAFT Capability Card 18 Nov 1998
not-before="1998-11-18T00:00:00Z"
not-after="1999-11-17T00:00:00Z">
<target uri="http://fujitsu.com/User/Sugano/schedule">
<short-text>Schedule</short-text>
</target>
<verifier uri="sisap://fujitsu.com/" />
<access-right label="project-partner">
<short-text>Get Sugano's Schedule</short-text>
</access-right>
<description>
<short-text>Sugano's Schedule Info</short-text>
</description>
</capability>
<capability
not-before="1998-11-18T00:00:00Z"
not-after="1999-11-17T00:00:00Z">
<target uri="http://fujitsu.com/User/Sugano/chat">
<short-text>chat page</short-text>
</target>
<verifier uri="sisap://fujitsu.com/" />
<access-right label="project-partner">
<short-text>Connect Sugano's channel</short-text>
</access-right>
<access-param>
charset="ISO-2022-JP"
</access-param>
<description>
<short-text>Chat to Sugano</short-text>
</description>
</capability>
<card-info card-id="SUGANO-USER-FUJITSU-COM-19981118000000-1"
issued-date="1998-11-18T00:00:00Z">
<short-text>SUGANO</short-text>
</card-info>
<issuer>
<user-info user-id="idip://fujitsu.com/User/Sugano">
<short-text>Hiroyasu SUGANO</short-text>
</user-info>
<vCard VERSION="3.0">
<fn>Hiroyasu Sugano</fn>
<tel tel.type="WORK""PREF">+81-78-123-xxxx</tel>
<adr del.type="POSTAL" "PARCEL" "WORK">
<street>64 Nishiwaki Ohkubo-cho</street>
<locality>Akashi</locality>
<region>Hyougo</region>
<pcode>674-8555</pcode>
<counry>JP</country>
</adr>
Otani/Sugano/Mitsuoka [Page 21]
INTERNET DRAFT Capability Card 18 Nov 1998
</vCard>
</issuer>
<subject>
<user-info user-id="idip://fujitsu.com/User/Otani">
<short-text>Koji Otani</short-text>
</user-info>
<pk-certificate>
-----BEGIN CERTIFICATE-----
MIIDRjCCAwQCBDWTL6gwCwYHKoZIzjgEAwUAMIGIMQswCQYDVQQGEwJqcDEPMA0GA1UECBMG
SHlvdWdvMQ8wDQYDVQQHEwZBa2FzaGkxHTAbBgNVBAoTFEZ1aml0c3UgTGFib3JhdG9yaWVz
MScwJQYDVQQLEx5JbmZvcm1hdGlvbiBTZXJ2aWNlIExhYm9yYXRvcnkxDzANBgNVBAMTBlN1
Z2FubzAeFw05ODA2MjYwNTIwNDBaFw05ODA5MjQwNTIwNDBaMIGIMQswCQYDVQQGEwJqcDEP
MA0GA1UECBMGSHlvdWdvMQ8wDQYDVQQHEwZBa2FzaGkxHTAbBgNVBAoTFEZ1aml0c3UgTGFi
b3JhdG9yaWVzMScwJQYDVQQLEx5JbmZvcm1hdGlvbiBTZXJ2aWNlIExhYm9yYXRvcnkxDzAN
BgNVBAMTBlN1Z2FubzCCAbcwggEsBgcqhkjOOAQBMIIBHwKBgQD9f1OBHXUSKVLfSpwu7OTn
9hG3UjzvRADDHj+AtlEmaUVdQCJR+1k9jVj6v8X1ujD2y5tVbNeBO4AdNG/yZmC3a5lQpaSf
n+gEexAiwk+7qdf+t8Yb+DtX58aophUPBPuD9tPFHsMCNVQTWhaRMvZ1864rYdcq7/IiAxmd
0UgBxwIVAJdgUI8VIwvMspK5gqLrhAvwWBz1AoGBAPfhoIXWmz3ey7yrXDa4V7l5lK+7+jrq
gvlXTAs9B4JnUVlXjrrUWU/mcQcQgYC0SRZxI+hMKBYTt88JMozIpuE8FnqLVHyNKOCjrh4r
s6Z1kW6jfwv6ITVi8ftiegEkO8yk8b6oUZCJqIPf4VrlnwaSi2ZegHtVJWQBTDv+z0kqA4GE
AAKBgCzvLBspFFcdRq4qgdcRfG2WVgJCYd2WFVpRFi1EzgI8iwkmClvvDYF6508BRdK42UaZ
8VBzV93Glb/pQ2qp5xuLlCI9j6f6tZPPLJ37vQVdSMSpWYQJysq97QlU3mI6/AhyFWs702n5
5LsqskCRlm3Na8mk7nTy7m5ogxyRxDALMAsGByqGSM44BAMFAAMvADAsAhRKzI0Z4fBlQI8G
hJa88XXkOugn6QIUcinz5Ay70iFwx+y0Ni93d94HMjI=
-----END CERTIFICATE-----
</pk-certificate>
</subject>
<delegation depth="1" propagate="true" width="-1"/>
</contents>
<signature algorithm="md5WithRSAEncryption">
MCwCFAZ5hmanpq3YKHjLssKYrPNZhANRAhQfqMStMdWqvqipc02vpnbLsLWZoQ==
</signature>
</capability-card>
[Example 2]
This card is a derived card from the one in Example 1 issued by
Otani. This card includes the original card in the "contents" ele-
ment. The subject of this card is Mitsuoka. His public key certifi-
cate is specified indirectly by the LDAP URL. The Verifier can get
his certificate from the LDAP server "ldap.fujitsu.com" with the URL
"ldap://ldap.fujitsu.com/o=Fujitsu%20Limited,c=JP??sub?(cn=Madoka%20Mitsuoka)".
Mitsuoka is given the same capabilities as those granted to Otani.
But since the value of "depth" attribute of "delegation" element is
0, Mitsuoka cannot delegate these capabilities to others.
Otani/Sugano/Mitsuoka [Page 22]
INTERNET DRAFT Capability Card 18 Nov 1998
<?xml version="1.0" encoding="UTF-8"?>
<capability-card>
<contents>
<capability-card>
<contents>
<capability
not-before="1998-11-18T00:00:00Z"
not-after="1999-11-17T00:00:00Z">
<target uri="http://fujitsu.com/User/Sugano/schedule">
<short-text>Schedule</short-text>
</target>
<verifier uri="sisap://fujitsu.com/" />
<access-right label="project-partner">
<short-text>Get Sugano's Schedule</short-text>
</access-right>
<description>
<short-text>Sugano's Schedule Info</short-text>
</description>
</capability>
<capability
not-before="1998-11-18T00:00:00Z"
not-after="1999-11-17T00:00:00Z">
<target uri="http://fujitsu.com/User/Sugano/chat">
<short-text>chat page</short-text>
</target>
<verifier uri="sisap://fujitsu.com/" />
<access-right label="project-partner">
<short-text>Connect Sugano's channel</short-text>
</access-right>
<access-param>
charset="ISO-2022-JP"
</access-param>
<description>
<short-text>Chat to Sugano</short-text>
</description>
</capability>
<card-info card-id="SUGANO-USER-FUJITSU-COM-19981118000000-1"
issued-date="1998-11-18T00:00:00Z">
<short-text>Sugano</short-text>
</card-info>
<issuer>
<user-info user-id="idip://fujitsu.com/User/Sugano">
<short-text>Hiroyasu SUGANO</short-text>
<vCard VERSION="3.0">
<fn>Hiroyasu Sugano</fn>
<tel tel.type="WORK""PREF">+81-78-123-xxxx</tel>
<adr del.type="POSTAL" "PARCEL" "WORK">
<street>64 Nishiwaki Ohkubo-cho</street>
Otani/Sugano/Mitsuoka [Page 23]
INTERNET DRAFT Capability Card 18 Nov 1998
<locality>Akashi</locality>
<region>Hyougo</region>
<pcode>674-8555</pcode>
<counry>JP</country>
</adr>
</vCard>
</user-info>
</issuer>
<subject>
<user-info user-id="idip://fujitsu.com/User/Otani">
<short-text>Koji Otani</short-text>
</user-info>
<pk-certificate>
-----BEGIN CERTIFICATE-----
MIIDRjCCAwQCBDWTL6gwCwYHKoZIzjgEAwUAMIGIMQswCQYDVQQGEwJqcDEPMA0GA1UECBMG
SHlvdWdvMQ8wDQYDVQQHEwZBa2FzaGkxHTAbBgNVBAoTFEZ1aml0c3UgTGFib3JhdG9yaWVz
MScwJQYDVQQLEx5JbmZvcm1hdGlvbiBTZXJ2aWNlIExhYm9yYXRvcnkxDzANBgNVBAMTBlN1
Z2FubzAeFw05ODA2MjYwNTIwNDBaFw05ODA5MjQwNTIwNDBaMIGIMQswCQYDVQQGEwJqcDEP
MA0GA1UECBMGSHlvdWdvMQ8wDQYDVQQHEwZBa2FzaGkxHTAbBgNVBAoTFEZ1aml0c3UgTGFi
b3JhdG9yaWVzMScwJQYDVQQLEx5JbmZvcm1hdGlvbiBTZXJ2aWNlIExhYm9yYXRvcnkxDzAN
dhjXBAMTBlN1Z2FubzCCAbcwggEsBgcqhkjOOAQBMIIBHwKBgQD9f1OBHXUSKVLfSpwu7OTn
9hG3UjzvRADDHj+AtlEmaUVdQCJR+1k9jVj6v8X1ujD2y5tVbNeBO4AdNG/yZmC3a5lQpaSf
n+EexAiwk+7qdf+t8Yb+DtX58aophADUEPuD9tPFHsMCNVQTWhaRMvZ1864rYdcq7/IiAxmd
0UgBxwIVAJdgUI8VIwvMspK5gqLrhAvwWBz1AoGBAPfhoIXWmz3ey7yrXDa4V7l5lK+7+jrq
gvlXTAs9B4JnUVlXjrrUWU/mcQcQgYC0SRZxI+hMKBYTt88JMozIpuE8FnqLVHyNKOCjrh4r
s6Z1kW6jfwv6ITVi8ftiegEkO8yk8b6oUZCJqIPf4VrlnwaSi2ZegHtVJWQBTDv+z0kqA4GE
AAKBgCzvLBspFFcdRq4qgdcRfG2WVgJCYd2WFVpRFi1EzgI8iwkmClvvDYF6508BRdK42UaZ
8VBzV93Glb/pQ2qp5xuLlCI9j6f6tZPPLJ37vQVdSMSpWYQJysq97QlU3mI6/AhyFWs702n5
5LsqskCRlm3Na8mk7nTy7m5ogxyRxDALMAsGByqGSM44BAMFAAMvADAsAhRKzI0Z4fBlQI8G
hJa88XXkOugn6QIUcinz5Ay70iFwx+y0Ni93d94HMjI=
-----END CERTIFICATE-----
</pk-certificate>
</subject>
<delegation depth="1" propagate="true" width="-1"/>
</contents>
<signature algorithm="md5WithRSAEncryption">
MCwCFAZ5hmanpq3YKHjLssKYrPNZhANRAhQfqMStMdWqvqipc02vpnbLsLWZoQ==
</signature>
</capability-card>
<card-info card-id="OTANI-USER-FUJITSU-COM-19981120000000-1"
issued-date="1998-11-20T00:00:00Z">
<short-text>Sugano</short-text>
</card-info>
<issuer>
<user-info user-id="idip://fujitsu.com/User/Otani">
<short-text>Koji Otani</short-text>
</user-info>
</issuer>
Otani/Sugano/Mitsuoka [Page 24]
INTERNET DRAFT Capability Card 18 Nov 1998
<subject>
<user-info user-id="idip://fujitsu.com/User/Mitsuoka">
<short-text>Madoka Mitsuoka</short-text>
</user-info>
<pk-certificate name="ldap://ldap.fujitsu.com/o=Fujitsu%20Limite
d,c=JP??sub?(cn=Madoka%20Mitsuoka)"/>
</subject>
<delegation depth="0"/>
</contents>
<signature algorithm="md5WithRSAEncryption">
MCwCFAZ5hmanpq3YKHjLxxKYrPUZhXNRAhQfqMStMdWqvqipc02vpnbLsLWZoQ==
</signature>
</capability-card>
7. References
[SPKI] C. M. Ellison, et al., "SPKI Certificate Theory", draft-ietf-
spki-cert-theory-03.txt, Work in Progress.
[VCARD] Internet Mail Consortium, "vCard - The Electronic Business
Card Version 2.1", http://www.imc.org/pdi/vcard-21.txt, Sep. 1996.
[MIME-VCARD] F. Dawson, and T. Howes, "VCard MIME Directory Profile",
RFC2426, Sep. 1998.
[XML] T. Bray, J. Paoli, and C.M. Sperberg-McQueen, "Extensible
Markup Language(XML)1.0", W3C Recommendation, W3C, Feb. 1998.
[VCARD-XML] F. Dawson, and P. Hoffman, "The vCard v3.0 XML DTD",
draft-dawson-vcard-xml-dtd-01.txt, Work in Progress.
8. Authors' Address
Koji Otani
Fujitsu Laboratories Ltd.
64 Nishiwaki, Ohkubo-cho
Akashi 674-8555, Japan
sho@flab.fujitsu.co.jp
Hiroyasu Sugano
Fujitsu Laboratories Ltd.
64 Nishiwaki, Ohkubo-cho
Akashi 674-8555, Japan
suga@flab.fujitsu.co.jp
Madoka Mitsuoka
Otani/Sugano/Mitsuoka [Page 25]
INTERNET DRAFT Capability Card 18 Nov 1998
Fujitsu Laboratories Ltd.
64 Nishiwaki, Ohkubo-cho
Akashi 674-8555, Japan
mitsuoka@flab.fujitsu.co.jp
Otani/Sugano/Mitsuoka [Page 26]
| PAFTECH AB 2003-2026 | 2026-04-23 17:00:44 |