[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [xacml] XACML DSig Profile draft
Attached is a draft of an XACML Digital Signature Profile. Comments are solicited. Perhaps we can discuss this at the next TC meeting. The draft is available in MSWord 97 and plain ASCII text formats. The text format was generated before I did a spellcheck, so please don't tell me about misspellings in that! Some references to other sections of the document are not realized, because I have been having trouble getting my word processor to handle them. Anne -- Anne H. Anderson Email: Anne.Anderson@Sun.COM Sun Microsystems Laboratories 1 Network Drive,UBUR02-311 Tel: 781/442-0928 Burlington, MA 01803-0902 USA Fax: 781/442-1692
Attachment:
p-aha-dsigprofile-01.doc
Description: XACML XMLDSig Profile
OASIS XACML XML DSig Profile
PROPOSAL 0.1, 15 January 2003
Document identifier:
p-aha-dsigprofile-03.doc
Location:
http://www.oasis-open.org/committees/xacml/repository/
Editor:
Anne Anderson, Sun Microsystems <anne.anderson@sun.com>
Contributors:
Abstract:
This document provides a profile for the use of the W3C
XML-Signature Syntax and Processing Standard in providing
authentication and integrity protection for XACML schema
instances.
Status:
This document is a Proposal submitted by Anne Anderson
<anne.anderson@sun.com>
XACML Committee members should send comments on this
specification to the xacml@lists.oasis-open.org list. Others
should subscribe to and send comments to the
xacml-comment@lists.oasis-open.org list. To subscribe, send an
email message to xacml-comment-request@lists.oasis-open.org with
the word "subscribe" as the body of the message.
For information on whether any patents have been disclosed that
may be essential to implementing this specification, and any
offers of patent licensing terms, please refer to the
Intellectual Property Rights section of the XACML TC web page
(http://www.oasis-open.org/committees/xacml/).
Table of Contents
1Introduction 3
1.1Terminology 3
2Word Styles 4
2.1Overall Style 4
2.2Title Page 4
2.3Headings 4
2.4Paragraphs 4
2.5Lists 4
2.6Tables 5
2.7Code Examples 5
2.8Character Styles 5
3References 7
3.1Normative 7
1Introduction
This document provides a profile for use of the W3C XML-Signature
Syntax and Processing Standard in protecting OASIS eXtensible
Access Control Markup Language [XACML] schema instances. Proper
use of can provide authentication and integrity protectiion for
XACML documents; see Sections 9.2.1 Authentication and 9.2.4
Policy integrity for more information about authentication and
integrity protection requirements. This profile SHOULD be
followed when designing protocols that will involve the
transmission of XACML Policy, PolicySet, Request, and Response
instances over insecure channels. Consistent use of this profile
will increase the portability and interoperability of signed
document fragments, as well as ensuring that is being used in a
way that provides the intended levels of protection.
1.1Terminology
The key words must, must not, required, shall, shall not, should,
should not, recommended, may, and optional in this profile are to
be interpreted as described in [RFC2119].
Other special terms used in this profile are defined below. When
these terms occur in the profile, they are display in bold font
to indicate that they are to be interpreted according to their
definitions in this list.
authentication , message - the property that the association
between an XACML document instance and its signature can be
verified.
authentication, signer - the property that the identity of the
entity that generated a given XACML document instance can be
verified to be as claimed.
canonicalization - the process of producing a standard,
reproducible representation for a document.
digest - see message digest.
digital signature - see signature.
document - used in this profile to refer to instances of the
XACML PolicySet, Policy, Request context, and Response context
schemas, as well as to any associated schemas themselves.
enveloped signature - a signature that is included in the
document that is being signed.
enveloping signature - a signature that includes the document
that is being signed within its <Signature> element.
detached signature - a signature that is not attached to its
associated signed document.. The signature neither enveopes nor
is enveloped by the signed document.
integrity - the property that unauthorized modifications to an
XACML document instance can be detected.
manifest - a structure defined by [XMLDSIG] that contains one or
more <Reference> elements, but is not part of a <Signature>
element. A <Reference> element in a <Signature> element may
contain the URL and message digest of a manifest.
message digest - the result of applying a one-way hash function
to a stream of bytes. Message digests are described in more
detail in Section .
policy - used in this profile to refer to instances of the XACML
PolicySet and XACML Policy schemas.
private key - a numeric value that is used, along with the digest
of the document to be signed, as input to the signature
algorithm. Each private key has one and only one associated
public key. The signer of a document must not reveal the value
of the private key that was used to create the signature. In
fact, it is possible to destroy the private key after a signature
has been generated.
public key - a numeric value that is used, along with the
signature value of a document, as input to the signature
verification algorithm. Each public key has one and only one
associated private key. The signer of a document can freely
share the value of any public key. The signer must share the
value of the public key with any signature verifier in order for
verification to be possible. Public keys can be shared securely
using Public Key Certificates.
Public Key Certificate - a signed digital structure containing
the name of some entity and the value of a public key for which
that entity owns the corresponding private key. A Public Key
Certificate is signed using a private key for which the public
key can be securely obtained, often using a chain of Public Key
Certificates.
sign - the proces of generating a signature.
signature - a value generated by the application of a private key
to an XACML document instance via a cryptographic algorithm such
that it has the properties of integrity, message authentication,
and/or signer authentication [adapted from Schneir].
static reference - used in this profile to mean use of a
<PolicyIdReference> or <PolicySetIdReference> where the policy
writer wishes to refer to the snapshot of the referenced policy
that existed at the time the referencing policy was written,
rather than to the current contents of the referenced policy at
the time the policy is to be evaluated.
transform - the process of converting an XML document into a
different XML document, often by removing, extracting, and/or
re-ordering pecified elements from the original XML document.
Any enveloped signature must include a transform algorithm that
will remove the signature value from the document before the
signature value is computed or verified.
verify - the process of checking the signature on a document to
verify that the signature and the document are consistent.
2XML Digital Signature Concepts
[This section is not normative.)
A digital signature is a security mechanism that can provide some
of the safeguards described in Section 9.2 of the [XACML]
specification. In particular, it can provide a means for
authentication of the source of an XACML document and a means for
ensuring the integrity of an XACML document.
An XML Digital Signature, as used in this profile, is an XML
element that contains
- information about the document that is being signed,
- the digital signature value itself , and
- information required to verify the signature.
In our case, the signed document is an XACML schema instance,
hereafter referred to as a document. Other XML documents, such
as schemas, may also need to be signed, and are included in the
term document.
This first section explains certain concepts from the [XMLDSIG]
specification that are needed to understand the application of a
digital signature to an XACML document.
2.1Digital signature
A signature is a value computed using a cryptographic algorithm
from a two digital values: the value of a message digest, (see
below) computed from the document being signed, and the value of
a private key known only to the signer of the document.
Associated with the private key is a public key that the signer
may freely distribute to potential verifiers of documents signed
using the private key. Public key values are usually distributed
in the form of Public Key Certificates.
The cryptographic algorithms used in generating a signature give
the signature several useful properties:
1.it is relatively easy to compute the signature value,
2.it is relatively easy to compute the message digest from the
signature value and the corresponding public key,
3.it is extremely difficult to determine the value of the private
key, given the signature value and the document or its message
digest.
Since there are several commonly used algorithms used for
generating digital signatures, a well-known identifier for the
algorithm used is included in the Signature element.
2.2Message digest
A message digest is a value computed using another cryptographic
algorithm from a digital representation of a document. The
cryptographic algorithms used in generating a message digest t
give the digest value several useful properties:
1. the digest value is relatively short,
2.the digest value is relatively easy to compute,
3.any change to the digital representation of the document, even
by so much as one bit, will cause the digest computed from the
document to have a different value,
4.it is extremely difficult to generate a document that will have
a given digest value, so difficult that huge numbers of hours on
incredibly powerful computers would be required.
Since there are several commonly used algorithms used for
generating message digests, a well-known identifier for the
algorithm used is included in the Signature element.
2.3Signature verification
Together, the properties of the message digest and the signature
mean that the receiver of a document and its associated signature
can relatively easily verify that the signature goes with the
provided document, that the signature was generated using the
private key associated with the known public key, and that the
document has not been modified since the signature was generated.
If the public key is provided in a Public Key Certificate, there
are similar ways to verify that the private key is owned by a
particular identity.
The document, the signature, and the Public Key Certificate may
be stored separately and retrieved separately by the verifier.
No additional protection of the channels by which these three
items are transmitted are required in order to preserve the
ability to perform verification of message authentication, signer
authentication, and integrity.
2.4Canonicalization
Remember that even a one bit difference in the value of the
document will result in a different message digest . This means
that the value of the document represented as an octet stream
used by the signer must be exactly identical to value of the
document used by the verifier. But the same XML document may
exist in many different forms: it may be encoded using a
different character set, it may be presented in a processed form
(such as a DOM or SAX representation), or certain values in the
document, such as QNames or default XML attribute values, may be
represented in different ways.
In order to ensure that the digital representation of the
document used by the verifier is identical to the digital
representation used by the signer, the signer processes the
document using a standard canonicalization method. A
canonicalization method is a procedure that expresses all
information in a document in a standard, invariable way. The
canonicalization method used by the signer is identified in the
Signature element so that the signature verifier can canonicalize
the document in the same way.
2.5Signature Element format
The [XMLDSIG] Signature element has the following structure
(where "?" denotes zero or one occurrence; "+" denotes one or
more occurrences; and "*" denotes zero or more occurrences):.
<Signature ID?>
<SignedInfo>
<CanonicalizationMethod/>
<SignatureMethod/>
<Reference URI? >
<Transforms/>?
<DigestMethod/>
<DigestValue/>
</Reference>+
</SignedInfo>
<SignatureValue/>
<KeyInfo/>?
<Object ID?/>*
</Signature>
The <Signature> element encompasses the digital signature. The
<Signature> element may or may not include the document being
signed. This will be described below in Section .
The <SignedInfo> element is the information that is actually
signed. First, the canonicalization algorithm specified in the
<CanonicalizationMethod> element is applied to the <SignedInfo>
element to produce a stream of octet values. Then the message
digest algorithm specified in the <SignatureMethod> element is
applied to that stream of octet values, producing a message
digest. Finally, the signature algorithm ispecified in the
<SignatureMethod> is applied to that message digest. The
resulting signature value is placed into the <SignatureValue>
element.
The <CanonicalizationMethod> element contains the identifier of
the canonicalization algorithm that is to be applied to the
<SignedInfo> element. The result of this canonicalization should
be a stream of octets that will be identical for a given
<SignedInfo> element value, regardless of its representation.
The <SignatureMethod> element contains the identifiers of the
signature and message digest algorithms. Each well-known
algorithm has a well-known identifier. The <SignatureMethod>
element> also contains the values of any parameters required by
the chosen algorithms.
<SignedInfo> may contain any number of <Reference> elements.
Each <Reference> element describes one document and the message
digest of the document contents. Once the signature value of the
<SignedInfo> element has been verified, the verifier can verify
that any document included in a <Reference> element in that
<SignedInfo> has not been modifed since the digest value included
in the <Reference> element was computed. The verifier does this
by independently computing the message digest value for the
document and comparing the resulting value with the value in the
<SignedInfo>'s <Reference> element. If they match, then the
document has not been changed and is the document that the
signer intended to reference.
2.6XMLDSig Signature Types
[XMLDSIG] Supports four ways of using signatures.
1.Enveloped Signature: The <Reference> points to the document
that contains the <SignedInfo> element itself. In this case, the
transform algorithm must remove the signature value from the
document before a message digest is calculated, since the
signature will not be known until the document is digested, but
once the signature is inserted, the digest of the document will
change.
2.Enveloping Signature: The <Reference> points to an <Object>
element that is included in the <Signature> element itself. This
allows a <Signature> to be a wrapper, or envelope, around one or
more signed documents.
3.Detached Signature: The <Reference> points to a document that
is external to the <Signature> element. This way of using
signatures allows a <Signature> element to be transported to a
verifier independently from the document that has been signed.
4.Signed Manifest:: The <Reference> element points to a special
[XMLDSIG]-defined Element called a Manifest. A Manifest is
similar to a <SignedInfo> element in that it contains one or more
<Reference> elements. The difference is that the rules for
<SignedInfo> require that every document in its <Reference>
elements must be retrieved and their message digests verified as
part of the verification of the <SignedInfo> signature. With a
Manifest, it is up to the application to decide which document
message digest values must be verified, and when. This makes a
Manifest useful when the verifier may not want to retrieve and
verify every referenced document.
3XACML XMLDSig Profile
(This section is normative.)
3.1Signature type
The only XMLDSig signature type that MAY NOT be used with an
XACML document is the enveloped signature. This is because there
is no element defined in the XACML schema that can contain a
signature that is embedded inside an XACML schema instance
document.
3.2Namespace elements in XACML documents
Any XACML document that is to be signed MUST specify all
namespace elements used in the document. If this is not done,
then the document will attract namespace definitions from
ancestors of the document that may differ from one envelope to
another.
3.3Namespace elements in signatures
Since <Signature> elements are usually embedded in some protocol
envelope, any <Signature> element MUST specify all namespace
elements used in the <Signature>. If this is not done, then the
<Signature> will attract namespace definitions from ancestors of
the <Signature> that may differ from one envelope to another.
3.4CanonicalizationMethod
The <CanonicalizationMethod> element in a <Signature> defines how
the <SignedInfo> element itself is to be canonicalized prior to
being digested. The <SignedInfo> element must be converted into
a specific, reproducible representation as an octet string in
order for the signature verifier and the signature signer to
produce the same message digest for the <SignedInfo> element.
Signatures for XACML documents SHOULD use either Canonical XML
(omits comments)
(http://www.w3.org/TR/2001/REC-xml-c14n-20010315) or Canonical
XML with Comments
(http://www.w3.org/TR/2001/REC-xml-c14n-20010315#WithComments).
Support for these two canonicalization algorithms are required in
any conforming XML DSig implementation. Use of just these two
algorithms will ensure that any PDP that supports standard XML
DSig will be able to canonicalize the document correctly in order
to verify the signature.
3.5Transform methods
The <Transforms> element in a <Reference> defines
canonicalizations and other transformations of the referenced
document that must be performed prior to being digested. The
referenced document must be converted into a specific,
reproducible representation as an octet string in order for the
signature verifier and the signature signer to produce the same
message digest for the referenced element.
Every <Signature> for an XACML document SHOULD contain either
Canonical XML (omits comments)
(http://www.w3.org/TR/2001/REC-xml-c14n-20010315) or Canonical
XML with Comments
(http://www.w3.org/TR/2001/REC-xml-c14n-20010315#WithComments) as
a transform method.
If the document being signed is Base64-encoded, then the Base64
Transform (http://www.w3.org/2000/09/xmldsig#base64) SHOULD be
used first.
If any XPath expressions are used in an XACML document, then the
XPath Filtering Transform
(http://www.w3.org/TR/1999/REC-xpath-19991116) SHOULD be used.
Support for the two specific transform methods is RECOMMENDED for
conforming XML DSig implementations, and support for the first
method, which is also a canonicalization method, is required.
Use of just these three transforms will make it much more likely
that any PDP that supports standard XML DSig will be able to
transform the document correctly in order to verify the
signature.
If an XACML document includes data elements that may be
represented in more than one form (such as (TRUE, FALSE), (1,0),
(true,false)), then a Transform method MUST be defined and
specified for normalizing those data elements. If this is not
done, the signer and the verifier may end up digesting different
octet streams, and the signature verification will fail.
3.6Message Digest algorithms
There is only one message digest algorithm that is required for
all conforming XMLDSig implementations: SHA-1, which has
identifier http://www.w3.org/2000/09/xmldsig#sha1.
Use of this message digest algorithm is recommended for
signatures of XACML documents.
3.7Signature algorithms
There are two signature algorithms described in the XMLDSig
specification: DSA, which has identifier
http://www.w3.org/2000/09/xmldsig#dsa-sha1, and PKCS1 (RSA-SHA1),
which has identifier http://www.w3.org/2000/09/xmldsig#rsa-sha1.
While neither of these algorithms is required for conforming
XMLDSig implementations, they are the algorithms most likely to
be supported, and so use of one of them in signing XACML
documents is recommended.
3.8Use of a Manifest
See the next two sections for a description of cases in which a
Manifest may be appropriate.
3.9Signing schemas
The parsing of any XACML document depends on having an accurate
copy of all schemas on which the XACML document depends. Note
that the inclusion of a schema URI in the XACML document element
attributes does not guarantee that an accurate copy of the schema
will be used: an attacker may substitute a bogus schema that
contains the same identifier as the correct schema. Signatures
can help protect against substitution or modification of the
schemas on which an XACML document depends. Use of signatures
for this purpose are described in this section.
In most cases, a document signer SHOULD include a <Reference>
element for each schema on which the XACML document depends in
the <SignedInfo> element that contains the <Reference> to the
XACML document itself.
In some cases, the document signer knows that all PDPs that will
evaluate a given XACML document will have accurate copies of
certainschemas needed to parse the document, and does not want to
force the PDP to verify the message digest for such schemas. In
these cases the document signer MAY omit <Reference> elements for
any schema whose verification is not needed.
If the document signer does not know for which schemas a PDP will
have an accurate copy, then the <SignedInfo> element that
contains the <Reference> to the XACML document itself SHOULD
contain a <Reference> to a <Manifest> element that, in turn,
contains a <References> to each schema on needed to parse the
XACML document. Use of a Manifest allows a PDP to verify the
signature on only those schemas for which the accuracy may be in
question.
3.10Integrity protection for referenced external policies
A policy signer must know the intent of the policy writer in
determining how to generate a signature for a policy that
contains references to other, external documents via the XACML
<PolicySetIdReference> and <PolicyIdReference> elements.
In many cases, a policy writer wishes to reference the current
version of another policy. This can be done by using the URL of
the other policy in a <PolicyIdReference> or
<PolicySetIdReference> element. Signing the referencing policy
does not depend on the contents of the referenced policies, so
the current version of the referenced policy may be used without
affecting the verification of the referencing policy.
In other cases, a policy writer wishes to reference a specific
snapshot of the contents of another policy. We will call this a
static reference. This can be done in either of two ways. The
most straightforward way is to include the desired contents of
the other policy as a <PolicySet> or <Policy> element. The
alternative way is to use the URL of the other policy in a
<PolicyIdReference> or <PolicySetIdReference> element, and then
to sign the referencing policy in such a way that the signature
includes the message digest of the referenced policy contents.
This second alternative is described in the rest of this section.
The recommended way of signing a policy along with one or more
static references is to use a Manifest. The <Manifest> element
SHOULD contain a <Reference> element for each static reference in
the original referencing policy. The <Reference> element for the
original referencing policy MAY be in either the <Manifest> or in
the <Signature> element.
The advantage of including the <Reference> for the original
referencing policy in the Manifest is that the Manifest then
becomes a package defining the policy and its static references.
The disadvantage of including the original referencing policy in
the Manifest is that verification of the <Signature> will not
automatically include retrieval and verification of the original
referencing policy, and this is almost always desired.
If the policy writer knows that every static reference must be
retrieved as part of policy evaluation, or if the policy writer
wishes to confirm that static references have not changed even if
they are not used during evaluation, then a Manifest is not
needed. In this case, the policy signer can include a
<Reference> element for each static reference inside the
<Signature> element of the original referencing policy itself ,
along with the <Reference> element for the original referencing
policy.
4Examples
{This section is NOT normative.}
4.1Basic signature for Policy1
This example shows a detached signature for a <Policy> instance
named "Policy1".
<Signature Id="Policy1Signature"
xmlns="http://www.w3.org/2000/09/xmldsig#";>
<SignedInfo>
<CanonicalizationMethod
Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
<SignatureMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#dsa-sha1"/>
<Reference
URI="http://www.sun.com/policies/Policy1.xml";>
<Transforms>
<Transform Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
</Transforms>
<DigestMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<DigestValue>?????</DigestValue>
</Reference>
</SignedInfo>
<SignatureValue>?????</SignatureValue>
<KeyInfo>
<KeyValue>
<DSAKeyValue>
<P>?????</P><Q>?????</Q><G>?????</G><Y>?????</Y>
</DSAKeyValue>
</KeyValue>
</KeyInfo>
</Signature>
4.2Basic signature for PolicySet1 and Policy1
This example shows a detached signature for a <PolicySet>
instance named "PolicySet1" that contains a <PolicyIdReference>
to a <Policy> instance named "Policy1". A Manifest is not used
in this example.
<Signature Id="PolicySet1Policy1Signature"
xmlns="http://www.w3.org/2000/09/xmldsig#";>
<SignedInfo>
<CanonicalizationMethod
Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
<SignatureMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#dsa-sha1"/>
<Reference
URI="http://www.sun.com/policies/PolicySet1.xml";>
<Transforms>
<Transform Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
</Transforms>
<DigestMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<DigestValue>?????</DigestValue>
</Reference>
<Reference
URI="http://www.sun.com/policies/Policy1.xml";>
<Transforms>
<Transform Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
</Transforms>
<DigestMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<DigestValue>?????</DigestValue>
</Reference>
</SignedInfo>
<SignatureValue>?????</SignatureValue>
<KeyInfo>
<KeyValue>
<DSAKeyValue>
<P>?????</P><Q>?????</Q><G>?????</G><Y>?????</Y>
</DSAKeyValue>
</KeyValue>
</KeyInfo>
</Signature>
4.3Enveloping signature for Manifest for PolicySet1 and Policy1
This example shows an enveloping signature for a Manifest. The
Manifest includes <Reference> elements for a <PolicySet> instance
named "PolicySet1" and for a <Policy> named "Policy1" that is
referenced from "PolicySet1". Note that the Manifest could have
been kept as a separate XML document, and not included in the
<Signature> element.
<Signature Id="PolicySet1Policy1ManifestSignature"
xmlns="http://www.w3.org/2000/09/xmldsig#";>
<SignedInfo>
<CanonicalizationMethod
Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
<SignatureMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#dsa-sha1"/>
<Reference
URI="#PolicySet1Policy1Manifest">
<Transforms>
<Transform Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
</Transforms>
<DigestMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<DigestValue>?????</DigestValue>
</Reference>
</SignedInfo>
<SignatureValue>?????</SignatureValue>
<KeyInfo>
<KeyValue>
<DSAKeyValue>
<P>?????</P><Q>?????</Q><G>?????</G><Y>?????</Y>
</DSAKeyValue>
</KeyValue>
</KeyInfo>
<Object>
<Manifest Id="PolicySet1Policy1Manifest">
<Reference
URI="http://www.sun.com/policies/PolicySet1.xml";>
<Transforms>
<Transform Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
</Transforms>
<DigestMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<DigestValue>?????</DigestValue>
</Reference>
<Reference
URI="http://www.sun.com/policies/Policy1.xml";>
<Transforms>
<Transform Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
</Transforms>
<DigestMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<DigestValue>?????</DigestValue>
</Reference>
</Manifest>
</Object>
</Signature>
5References
5.1Normative
[RFC2119] S. Bradner, Key words for use in RFCs to Indicate
Requirement Levels, http://www.ietf.org/rfc/rfc2119.txt, IETF RFC
2119, March 1997.
[XACML] S. Godik, T. Moses, OASIS eXtensible Access Control
Markup Language (XACML), Committee Specification Version 1.0
(Revision 1),
http://www.oasis-open.org/committees/xacml/repository/cs-xacml-specification-01.doc
or
http://www.oasis-open.org/committees/xacml/repository/cs-xacml-specification-01.pdf,
12 December 2002.
[XMLDSIG] D. Eastlake, et al., W3C XML-Signature Syntax and
Processing, W3C Recommendation,
http://www.w3.org/TR/xmldsig-core, 12 February 2002.
Appendix A.Acknowledgments
The following individuals were members of the committee during
the development of this specification:
Jane Doe, Example Corp.
A. Nonymous (chair), Example Corp.
John Smith, Example Corp.
Karl Best, OASIS
John Doe, Other Examples, Inc.
Eve Maler, Sun Microsystems
Norman Walsh, Sun Microsystems
In addition, the following people made contributions to this specification:
Joe Blow, Example Corp.
Appendix B.Revision History
Rev
Date
By Whom
What
p-03
2003-01-15
Anne Anderson
Initial version
Appendix C.Notices
OASIS takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described
in this document or the extent to which any license under such
rights might or might not be available; neither does it represent
that it has made any effort to identify any such
rights. Information on OASIS's procedures with respect to rights
in OASIS specifications can be found at the OASIS website. Copies
of claims of rights made available for publication and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the
use of such proprietary rights by implementors or users of this
specification, can be obtained from the OASIS Executive Director.
OASIS invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to
implement this specification. Please address the information to
the OASIS Executive Director.
Copyright © OASIS Open 2002. All Rights Reserved.
This document and translations of it may be copied and furnished
to others, and derivative works that comment on or otherwise
explain it or assist in its implementation may be prepared,
copied, published and distributed, in whole or in part, without
restriction of any kind, provided that the above copyright notice
and this paragraph are included on all such copies and derivative
works. However, this document itself does not be modified in any
way, such as by removing the copyright notice or references to
OASIS, except as needed for the purpose of developing OASIS
specifications, in which case the procedures for copyrights
defined in the OASIS Intellectual Property Rights document must
be followed, or as required to translate it into languages other
than English.
The limited permissions granted above are perpetual and will not
be revoked by OASIS or its successors or assigns.
This document and the information contained herein is provided on
an "AS IS" basis and OASIS DISCLAIMS ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE
OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY
IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR
PURPOSE.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC