**OGSA Basic Profile 1.0**

[Status of This Memo]{.underline}

This memo provides a recommendation to the Grid community on how to
write normative OGSA services. The intention of this profile is to
describe precisely the requirements placed on implementations of such
services to ensure interoperability. Distribution is unlimited.

[Copyright Notice]{.underline}

Copyright © Global Grid Forum (2005). All Rights Reserved.

# Abstract {#abstract .unnumbered}

The growing number of Web service specifications makes it important to
understand and define the interaction and use of these specifications to
ensure interoperability. Within the context of basic Web services, it
has proved useful to define a collection of normative profiles that
provide guidance on issues of interoperability: the WS-I Basic Profile
v1.1 \[WS-I BP 1.1\] and the WS-I Basic Security Profile v1.0 \[WS-I BSP
1.0\]. Guided besthe principle of interoperation through conformance
specification and operating in the wider technical domain of distributed
system management and grid computing, we define here the OGSA Basic
Profile 1.0, the first of what is expected to become a set of normative
profiles addressing issues relating to distributed system management.

The OGSA Basic Profile 1.0 described in this document is a GGF
Recommended Profile in the sense of the document OGSA Profile Template
informational document \[ogsa-profile-template, meaning that it
describes uses of widely accepted specifications that have been found to
enable interoperability. The specifications considered in this profile
are, in general, those associated with the addressing, modeling, and
management of state: specifically, WS-Addressing \[WS-Addressing\],
WS-ResourceProperties \[WS-ResourceProperties\], WS-ResourceLifetime
\[up, WS-BaseNotification \[WS-BaseNotification\], and WS-BaseFaults
\[WS-BaseFaults\].

[Contents]{.underline}

[Abstract 1](#abstract)

[1 Introduction 3](#introduction)

[1.1 Profile Overview 3](#profile-overview)

[1.2 Relationships to Other Profiles
3](#relationships-to-other-profiles)

[1.3 Notational Conventions 4](#notational-conventions)

[1.4 Profile Identification and Versioning
4](#__RefHeading___Toc101166506)

[2 Profile Conformance 4](#__RefHeading___Toc101166510)

[2.1 Conformance Targets 4](#conformance-targets)

[2.2 Claiming Conformance 5](#claiming-conformance)

[3 Addressing 5](#addressing)

[3.1 Endpoint Reference 5](#endpoint-reference)

[4 Resource Property 6](#resource-property)

[4.1 Resource Property Definition 6](#__RefHeading___Toc101166560)

[4.2 GetMultipleResourceProperties 6](#getmultipleresourceproperties)

[4.3 QueryResourceProperties 7](#queryresourceproperties)

[4.4 ResourceProperty Change Notification
7](#resourceproperty-change-notification)

[5 Resource Lifetime 7](#resource-lifetime)

[5.1 Immediate Resource Termination 8](#immediate-resource-termination)

[5.2 Notification of Resource Destruction
8](#notification-of-resource-destruction)

[6 Base Notification 8](#base-notification)

[6.1 Notification Producer 8](#notification-producer)

[7 Base Faults 9](#base-faults)

[7.1 Base Faults 9](#__RefHeading___Toc101166610)

[8 Security 10](#security)

[8.1 Basic Security Profile Version 1.0
10](#basic-security-profile-version-1.0)

[Author Information 11](#author-information)

[Contributors 12](#contributors)

[Acknowledgements 12](#acknowledgements)

[Intellectual Property Statement 12](#intellectual-property-statement)

[Full Copyright Notice 12](#full-copyright-notice)

[Normative References 12](#normative-references)

[Non-Normative References 13](#non-normative-references)

[Appendix A. KeyInformation Exchange Normative Description
14](#__RefHeading___Toc101166620)

[1.1 Introduction 14](#introduction-1)

[8.2 Use cases 14](#__RefHeading___Toc101166622)

[8.3 Namespaces 14](#__RefHeading___Toc101166623)

[8.4 Example 14](#__RefHeading___Toc101166624)

[8.5 Infoset 15](#__RefHeading___Toc101166625)

[8.6 Interoperability 16](#__RefHeading___Toc101166626)

[8.7 Reference 16](#__RefHeading___Toc101166627)

# Introduction

This document defines the OGSA Basic Profile 1.0 (hereafter,
\"Profile\"), consisting of a set of non-proprietary Web services
specifications, along with clarifications, refinements, interpretations
and amplifications of those specifications that promote interoperability
among implementations of those specifications.

Section 1 introduces the Profile, and explains its relationships to
other profiles.

Section 2, \"Profile Conformance,\" explains what it means to be
conformant to the Profile.

Each subsequent section addresses a component of the Profile, and
consists of two parts; an overview detailing the component
specifications and their extensibility points, followed by subsections
that address individual parts of the component specifications. Note that
there is no relationship between the section numbers in this document
and those in the referenced specifications.

##  Profile Overview

The Profile is intended for use when implementing services that are
concerned with distributed resource management, grid computing, or other
purposes that involve the modeling and management of stateful entities.
These services frequently can benefit from the use of interfaces and
behaviors defined in the WS-Addressing, WS-Resource framework, and
WS-Notification families of specifications. A service implementation
that uses those specifications in a manner conformant with the Profile
may be said to be "conformant with the OGSA Base Profile 1.0" or,
informally, to be an "OGSA service."

The primary issues addressed in the profile are as follows:

-   Addressing: The Profile mandates the use of WS-Addressing endpoint
    references and places some constraints on their structure, thus
    enabling interoperable addressing. The Profile also defines an
    (optional) approach to encoding and using policy information for
    renewing invalid endpoint references, thus facilitating
    interoperable implementation of "resilient" references for those
    applications that require this support.

-   Resource Properties: The Profile mandates that a resource support
    certain resource properties, thus facilitating introspecation, and
    also mandates support for certain operations that are optional in
    the WS-ResourceProperties specifications. Both sets of requirements
    facilitate interoperability by allowing a client to make more
    assumptions about a service's interfaces.

-   Resource Lifetime: mandates the use of ResourceLifetime portTypes
    for immediate and scheduled termination of resources,

-   

-   Base Notification: [XXX]{.mark}

[]{.mark}

-   Base Faults: [XXX]{.mark}

This is not a complete list: see the sections that follow for details.

## Relationships to Other Profiles

[TBD. Say something about WS-I Basic Profile]{.mark} [1.1,
perhaps?]{.mark}

[And WS-I Basic Security Profile 1.0]{.mark}

## Notational Conventions 

The keywords \"MUST\", \"MUST NOT\", \"REQUIRED\", \"SHALL\", \"SHALL
NOT\", \"SHOULD\", \"SHOULD NOT\", \"RECOMMENDED\", \"MAY\", and
\"OPTIONAL\" in this document are to be interpreted as described in
[RFC2119](http://www.ietf.org/rfc/rfc2119.txt).

Normative statements of requirements in the Profile (i.e., those
impacting conformance, as outlined in \"[Conformance
Requirements](#conformance_requirements)\") are presented in the
following manner:

As with requirement statements, extensibility statements can be
considered namespace-qualified.

This specification uses a number of namespace prefixes throughout; their
associated URIs are listed below. Note that the choice of any namespace
prefix is arbitrary and not semantically significant.

-   

-   

-   

-   

-   

-   **wsrf-rp** -
    \"http://docs.oasis-open.org/wsrf/2004/11/wsrf-WS-ResourceProperties-1.2-draft-05.xsd"

-   **wsrf-rpw** -
    \"http://docs.oasis-open.org/wsrf/2004/11/wsrf-WS-ResourceProperties-1.2-draft-05.wsdl"

-   **wsrf-rl** - \"http
    http://docs.oasis-open.org/wsrf/2004/11/wsrf-WS-ResourceLifetime-1.2-draft-04.xsd\"

-   **wsrf-rlw** -
    \"http://docs.oasis-open.org/wsrf/2004/11/wsrf-WS-ResourceLifetime-1.2-draft-04.wsdl\"

-   

-   

-   **wsrf-bf** -
    \"http://docs.oasis-open.org/wsrf/2004/11/wsrf-WS-BaseFaults-1.2-draft-03.xsd\"

-   

[]{#__RefHeading___Toc101166506 .anchor}Profile Identification and
Versioning

Profile identification and versioning uses the style described in WS-I
Basic Profile 1.1 and abides by the normative descriptions contained
therein..

[]{#__RefHeading___Toc101166510 .anchor}Profile Conformance

Conformance to the Profile is defined normatively in WS-I Basic Profile
1.1. This Profile abides by those definitions.

##  Conformance Targets 

Since OGSA BP 1.0 is an extension of the WS-I Basic Profile 1.1 it may
place further restrictions on conformance targets defined in WS-I Basic
Profile 1.1. Further, this specification defines an additional
conformance target called ENDPOINTREFERENCE.

The following conformance targets are used in the Profile:

-   **ENDPOINTREFERENCE** -- the serialization of the
    wsa:EndpointReference and its content

-   

-   

-   

-   

-   

-   

-   **ENVELOPE** - the serialization of the soap:Envelope element and
    its content

-   **DESCRIPTION** - descriptions of types, messages, interfaces and
    their concrete protocol and data format bindings, and the network
    access points associated with Web services (e.g., WSDL descriptions)
    (from Basic Profile 1.1)

-   **INSTANCE** - software that implements a wsdl:port or a
    uddi:bindingTemplate (from Basic Profile 1.1)

-   **CONSUMER** - software that invokes an INSTANCE (from Basic Profile
    1.1)

-   **SENDER** - software that generates a message according to the
    protocol(s) associated with it (from Basic Profile 1.1)

-   **RECEIVER** - software that consumes a message according to the
    protocol(s) associated with it (e.g., SOAP processors) (from Basic
    Profile 1.1)

## 

## Claiming Conformance 

Claims of conformance to the Profile are the same as normatively
described in WS-I Basic Profile 1.1.

-   

-   

-   The conformance claim URI for this Profile is
    "http://www.ggf.org/namespaces/2005/03/OGSABasicProfile-1.0".

# Addressing

This section of the Profile incorporates the following specifications by
reference, and defines extensibility points within them:

-   Web Services Addressing \[WS-Addressing\]\
    Extensibility points:

    -   

    -   E0301 -- WSA Extensibility -- WS-Addressing allows extensibility
        elements for the wsa:EndpointReference.

## Endpoint Reference

The following specifications (or sections thereof) are referred to in
this section of the Profile:

-   Web Services Addressing, Section 2 \[WS-Addressing\]

WSA defines the endpoint reference structure for referencing Services
and WS-Resources. The Profile mandates the use of that structure, and
places the following constraints on its use:

### Endpoint Reference Structure

*R0301 An ENDPOINTREFERENCE MUST conform to the structure specified in
Web Services Addressing Section 2, \"Endpoint References\" (subject to
amendment by the Profile).*

### 

### 

### 

### 

### 

### Resilient Endpoint References

WS-Addressing does not provide a normative mechanism for creating
resilient endpoint references: i.e., an endpoint reference that can be
"renewed" from some source when it becomes invalid. An OGSA service may
require a resilient endpoint reference. To accomplish this, resiliency
metadata MAY be included in an endpoint reference.

*R0305 An ENDPOINTREFERENCE MAY contain zero or more
ogsa-bp:resilientReference extensibility elements from the*
http://www.ggf.org/namespaces/2005/03/OGSABasicProfile-1.0 *namespace to
specify the endpoint reference for a reference resolution service.*

*R0306* *A reference resolution INSTANCE MUST support the
ogsa-rns:Resolve message exchange to allow for the re-resolution of the
endpoint reference.*

*R0307 A reference resolution INSTANCE MUST support the ogsa-rns:Resolve
message exchange to allow for the re-resolution of the endpoint
reference.*

*R0308 A CONSUMER of an endpoint reference that contains an
ogsa-bp:resilientReference extensibility element SHOULD send an
ogsa-rr:Resolve message exchange to the ogsa-bp:resilientReference in
response to a wsrf-rap:ResourceUnknownFault.*

### 

-   
-   
-   
-   
-   

### Resource Property

This section of the Profile incorporates the following specifications by
reference, and defines extensibility points within them:

-   Web Services Resource Properties 1.2 \[WS-ResourceProperties\]\
    Extensibility points:

    -   E0401 -- Resource Property Document Extensibility -- Any
        resource property document MAY include standard xml
        extensibility through the use of xsd:any.

    -   E0402 -- Resource Property Element Extensibility -- Any resource
        property element MAY include standard xml extensibility through
        the use of xsd:any.

    -   E0403 -- QueryExpression Extensibility -- The Query Expression
        supported by the QueryResourceProperties message exchange is
        defined as open content (xsd:any).

-   -   
    -   

[]{#__RefHeading___Toc101166560 .anchor}Resource Property Definition

WS-ResourceProperty does not define any resource property elements. In
contrast, the Profile requires several resource property elements for
introspection purposes. The Profile mandates the use of these resource
property elements, and places the following constraints on its use:

### ResourcePropertyNames Resource Property Element Description

The ability to retrieve, through the GetResourceProperty message
exchange pattern, a list of all Resource Property element QNames in the
instance of a WS-Resource is required.

*R0411 A DESCRIPTION MUST contain in the Resource Property Document a
Resource Property Element ogsa-bp:ResourcePropertyNames as defined in
the schema*
*h*ttp://www.ggf.org/namespaces/2005/03/OGSABasicProfile-1.0.xsd*.*

*R0412 An INSTANCE MUST respond to a retrieval request for the QName
ogsa:ResourcePropertyNames with the complete list of the xs:QNames of
all known Resource Property Elements in the Resource Property Document
at the time of receipt of the message.*

### 

### GetMultipleResourceProperties

WS-ResourceProperty defines a portType for retrieval of multiple
resource properties. The Profile mandates the use of this portType, and
places the following constraints on its use:

### wsrf-rp:GetMultipleResourceProperties Message Exchange

WS-ResourceProperties only requires that an instance of a WS-Resource
implement the GetResourceProperty message exchange pattern. The Profile
also requires support for GetMultipleResourceProperties

*R0421* *A DESCRIPTION MUST include the
wsrf-rp:GetMultipleResourceProperties* *as defined in*
*WS-ResourceProperties* *section* *5.3.*

*R0422 An INSTANCE MUST support the GetMultipleResourceProperties
message exchange to allow for the retrieval of multiple resource
properties.*

## QueryResourceProperties

WS-ResourceProperty defines a portType for query and retrieval resource
properties. The Profile mandates the use of this portType, and places
the following constraints on its use:

### wsrf-rp:QueryResourceProperties Message Exchange

WS-ResourceProperties only requires that an instance of a WS-Resource
implement the GetResourceProperty message exchange pattern. The Profile
also requires support for QueryResourceProperties.

*R0431* *A DESCRIPTION SHOULD include the
wsrf-rp:QueryResourceProperties* *as defined in* *WS-ResourceProperties*
*section 5.4.*

*R0432 An INSTANCE SHOULD support the wsrf-rp:QueryResourceProperties
message exchange to allow for the query and retrieval of multiple
resource properties*

*R0433 An INSTANCE MUST support the QueryExpression Dialect URI*
<http://www.w3.org/TR/1999/REC-xpath-19991116> *on the
QueryResourceProperties message exchange.*

*R0434 An INSTANCE when presented with a resource property retrieval for
the QName wsrf-rp:QueryExpressionDialect response MUST (at least)
include the URI* <http://www.w3.org/TR/1999/REC-xpath-19991116>*.*

*R0434* *A MESSAGE response for wsrf-rp:QueryResourceProperties with the
Dialect URI* <http://www.w3.org/TR/1999/REC-xpath-19991116> *MUST
conform to the structure/serialization as defined in* *[XML Digital
Signature]{.mark}* *[Cannonicalization.]{.mark}*

## ResourceProperty Change Notification

WS-ResourceProperty RECOMMENDS change notifications for WS-Resources
that support the wsnt:NotificationProducer portType. OGSA services
fundamentally rely on the ability to understand changes in other OGSA
services. The Profile mandates the use of
ResourcePropertyChangeNotifications, and places the following
constraints on its use:

### Use of wsn:NotificationProducer

[xxxxxxx]{.mark}

*R0409 An INSTANCE MUST support wsn:Subscribe message exchange to allow
for creation of ResourcePropertyChangeNotifications.*

## 

### 

## Resource Lifetime

This section of the Profile incorporates the following specifications by
reference, and defines extensibility points within them:

-   [Web Services Resource Lifetime
    1.2](http://docs.oasis-open.org/wsrf/2004/11/wsrf-WS-ResourceProperties-1.2-draft-05.pdf)\
    Extensibility points:

    -   E0501 -- Termination Reason -- The termination reason in the
        TerminationNotification message type allows for open content
        (xsd:any).

## Immediate Resource Termination

WS-ResourceLifetime defines a portType for immediate termination of a
WS-Resource. The Profile mandates the use of this portType for explicit
destruction of resources, and places the following constraints on its
use:

### wsrf-rl:Destroy Message Exchange

WS-ResourceLifetime does not require that an instance of a WS-Resource
implement any of the message exchanges that it defines. In contrast, the
Profile mandates immediate destruction capability for WS-Resource
instances, which are created as a result of a message exchange.

*R0511* *A* *DESCRIPTION* *MUST* *include* *the wsrf-rl:Destroy message
exchange to allow for the immediate destruction of a WS-Resource.*

*R0512 An INSTANCE MUST support the wsrf-rl:Destroy message exchange to
allow for the immediate destruction of a WS-Resource.*

## 

## 

### 

### 

## Notification of Resource Destruction

WS-ResourceLifetime defines a topic space and message types to support
the ability of notification of destruction of WS-Resources. This
capability is optional in WS-ResourceLifetime. The Profile mandates the
use of this mechanism for notification of the destruction of resources,
and places the following constraints on its use:

### ResourceDestruction Notification

xxxxxxx\.

.

*R0502 An INSTANCE MUST xxxxxx,*

## 

### 

## 

## 

-   -   
    -   

### 

## Base Notification

This section of the Profile incorporates the following specifications by
reference, and defines extensibility points within them:

-   [Web Services Base Notification
    1.2](http://docs.oasis-open.org/wsn/2004/06/wsn-WS-BaseNotification-1.2-draft-03.pdf)\
    Extensibility points:

    -   E0601 -- Subscribe Topic Expression -- The topic expression in
        the wsnt:Subscribe is open content (xsd:any).

## Notification Producer

The Profile mandates the use of this portType for client controlled
collections of resources, and places the following constraints on its
use:

### Subscribe Message Exchange 

The wsnt:Subscribe message exchange allows for notification messages to
be sent over protocols other then web services based protocols. This
flexibility impedes interoperability of OGSA BP services. OGSA BP allows
the use of this message exchange but places the following constraints:

*R0601 A CONSUMER MUST NOT include the wsnt:UseNotify element in the
wsnt:Subscribe request. (wsnt:UseNotify defaults to 'true' thus forcing
notifications to be sent via web services protocols).*

*R0602 An INSTANCE MUST support the TopicExpression Dialect URI*
<http://docs.oasis-open.org/wsn/2004/06/TopicExpression/Simple> *for
wsnt:Subscribe/wsnt:TopicExpression@Dialect in the wsnt:Subscribe
message exchange.*

*R0603 An INSTANCE when presented with a resource property retrieval for
the QName wsnt:TopicExpressionDialect the response MUST include (at a
minimum) the URI*
<http://docs.oasis-open.org/wsn/2004/06/TopicExpression/Simple>*.*

*R0604* *An INSTANCE MAY respond with a 'precondition not supported'
fault if when the wsnt:Precondition element is present in the
wsnt:Subscribe message exchange.*

*R0605* *An INSTANCE MAY respond with a 'selector not supported' fault
if when the wsnt:Selector element is present in the wsnt:Subscribe
message exchange.*

*R0606* *An INSTANCE MAY respond with a 'subscription policy not
supported' fault if when the wsnt:SubscriptionPolicy element is present
in the wsnt:Subscribe message exchange.*

*R0607 An INSTANCE that accepts wsnt:Precondition element in the
wsnt:Subscribe message exchange MUST support the QueryExpression from
the namespace* <http://www.w3.org/TR/1999/REC-xpath-19991116> *as the
content for the wsnt:Precondition element.*

*R0608 An INSTANCE that accepts wsnt:Selector element in the
wsnt:Subscribe message exchange MUST support the QueryExpression from
the namespace* <http://www.w3.org/TR/1999/REC-xpath-19991116> *as the
content for the wsnt:Selector element.*

### Notification

WS-BaseNotification specifies that a NotificationProducer MAY send the
Notify message to the NotificationConsumer in order to deliver one or
more NotificationMessage(s). This is to allow for the use of 'raw'
notifications. Raw notifications are disallowed above by
R0601.therefore:

*R0609 An INSTANCE MUST send the wsnt:Notify message to the
NotificationConsumer in order to deliver one or more
NotificationMessage(s).*

# Base Faults

This section of the Profile incorporates the following specifications by
reference, and defines extensibility points within them:

-   

-   [Web Services Base
    Faults](http://docs.oasis-open.org/wsrf/2004/11/wsrf-WS-BaseFaults-1.2-draft-03.pdf)

## Base Faults

The following specifications (or sections thereof) are referred to in
this section of the Profile:

-   [WS-BaseFaults, Section
    2](http://docs.oasis-open.org/wsrf/2004/11/wsrf-WS-BaseFaults-1.2-draft-03.pdf)

[WS](http://docs.oasis-open.org/wsrf/2004/11/wsrf-WS-BaseFaults-1.2-draft-03.pdf)-BaseFaults
defines the fault structure that WS-Resources use for faults that are
generated by the WS-Resource. The Profile mandates the use of that
structure, and places the following constraints on its use:

### BaseFault Structure

*R0711* *A* *MESSAGE for a fault from a WS-Resource* *MUST conform to
the structure specified in* *Web Services Base Faults* *Section 2,
\"Base Fault Type\" (subject to amendment by the Profile).*

# Security

## Basic Security Profile Version 1.0

The following specifications (or sections thereof) are referred to in
this section of the Profile:

-   [Basic Security Profile Version
    1.0](http://www.ws-i.org/Profiles/BasicSecurityProfile-1.0-2004-05-12.html)

-   [HTTP over TLS](http://www.ietf.org/rfc/rfc2818.txt)

-   [The TLS Protocol](http://www.ietf.org/rfc/rfc2246.txt)

The Basic Security Profile defines a number of mechanisms for
communicating authentication information from a SENDER to a RECEIVER.
The Profile mandates the use of these, and places the following
constraints on its use:

### Mandated Secure Transport

All messages are subject to interference and corruption during
transmission. The Profile mandates secure transmission of messages.

*R0801 When establishing an HTTP connection a SENDER MUST use HTTP over
TLS as profiled by Base Security Profile Version 1.0 Section 4 and
Section 10.*

*R0802 When establishing an HTTP connection a RECEIVER MUST use HTTP
over TLS as profiled by Base Security Profile Version 1.0 Section 4 and
Section 10.*

*R0803 When establishing a non-HTTP connection a SENDER MUST use The TLS
Protocol and be compliant with Base Security Profile Version 1.0 Section
10.*

*R0804 When establishing a non-HTTP connection a RECEIVER MUST use The
TLS Protocol and be compliant with Base Security Profile Version 1.0
Section 10.*

Approaches to message level security alone do not protect the entire
message. The Profile mandates minimal transport level security in line
with the Basic Security Profile Version 1.0.

### Authentication

Consumers and instances must provide authentication information.

*R0806 The INSTANCE MUST provide authentication information as part of
the TLS connection.*

*R0807 The CONSUMER MUST provide authentication information as part of
the TLS connection or by adhering to Basic Security Profile Version 1.0
Section 7.*

The Profile mandates that there is no anonymous communication. To
provide interoperability only X509 certificate based authentication is
permitted by the Profile.

### Token Format Compliance

All security tokens used in message must comply with the Basic Security
Profile Version 1.0.

*R0808 When security tokens are included in the message the CONSUMER
MUST adhere to the Basic Security Profile Version 1.0 Section 5.*

The Basic Security Profile Version 1.0 mandates some details about how
security tokens must be handled to support interoperability.

### XML Signature

All messages employing XML Signature must comply with the Basic Security
Profile Version 1.0.

*R0809When using XML Signature a SENDER MUST comply with Basic Security
Profile Version 1.0, Section 8.*

*R0810 When using XML Signature a RECEIVER MUST comply with Basic
Security Profile Version 1.0, Section 8.*

### XML Encryption

All messages employing XML Encryption must comply with the Basic
Security Profile Version 1.0.

*R0811 When using XML Encryption a SENDER MUST comply with Basic
Security Profile Version 1.0, Section 9.*

*R0812 When using XML Encryption a RECEIVER MUST comply with Basic
Security Profile Version 1.0, Section 9.*

### Message Level Security

All messages which are secured using message level security MUST employ
XML encryemploying XML Encryption must comply with the Basic Security
Profile Version 1.0.

*R0813* *When using* *Message Level Security the ENDPOINTREFERENCE*
*SHOULD* *include* *[xxx]{.mark}:KeyInfoElement* *as defined in Appendix
A.*

# Author Information {#author-information .unnumbered}

Ian Foster

Math & Computer Science Division

Argonne National Laboratory

Argonne, IL 60439

Email:
\<[foster@mcs.anl.gov](mailto:foster@mcs.anl.gov?subject=draft-ggf-ogsa-basic-profile-004)\>

Tom Maguire

IBM

2455 South Road

Poughkeepsie, NY 10509

Email:
\<[tmaguire@us.ibm.com](mailto:tmaguire@us.ibm.com?subject=draft-ggf-ogsa-basic-profile-002)\>

Dr. David Snelling

Fujitsu Laboratories of Europe

Hayes Park Central

Hayes End Road

Hayes, Middlesex UB4 8FE

Email:
\<[d.snelling@fle.fujitsu.com](mailto:d.snelling@fle.fujitsu.com?subject=draft-ggf-ogsa-basic-profile-002)\>

# Contributors {#contributors .unnumbered}

We gratefully acknowledge the contributions made to this specification
by.

# Acknowledgements {#acknowledgements .unnumbered}

We are grateful to numerous colleagues for discussions on the topics
covered in this document, in particular (in alphabetical order, with
apologies to anybody we\'ve missed).

# Intellectual Property Statement {#intellectual-property-statement .unnumbered}

The GGF 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. 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 implementers or
users of this specification can be obtained from the GGF Secretariat.

The GGF 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 practice this
recommendation. Please address the information to the GGF Executive
Director.

# Full Copyright Notice {#full-copyright-notice .unnumbered}

Copyright (C) Global Grid Forum (2005). 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
may not be modified in any way, such as by removing the copyright notice
or references to the GGF or other organizations, except as needed for
the purpose of developing Grid Recommendations in which case the
procedures for copyrights defined in the GGF Document process 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 the GGF or its successors or assigns.

This document and the information contained herein is provided on an
\"AS IS\" basis and THE GLOBAL GRID FORUM 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.\"

# Normative References {#normative-references .unnumbered}

**\[****RFC 2119\]** S. Bradner, *Key words for use in RFCs to Indicate
Requirement Levels*, <http://www.ietf.org/rfc/rfc2119.txt>, IETF RFC
2119, March 1997.

**\[****URI\]** T. Berners-Lee, R. Fielding, L. Masinter, *Uniform
Resource Identifiers (URI): Generic Syntax*, RFC 2396, MIT/LCS, U.C.
Irvine, Xerox Corporation, August 1998.

**\[ogsa-profile-template\]**
<http://forge.gridforum.org/projects/ogsa/document/draft-ggf-ogsa-profile-template/en/3>

**\[****WS-Addressing\]**
<http://www.w3.org/Submission/2004/SUBM-ws-addressing-20040810>

**\[WS-BaseFaults\]**
<http://docs.oasis-open.org/wsrf/2004/11/wsrf-WS-BaseFaults-1.2-draft-03.pdf>

**\[****WS-BaseNotification\]**
[http://docs.oasis-open.org/wsn/2004/06/wsn-WS-BaseNotification-1.2-draft-03.pdf](http://docs.oasis-open.org/wsn/2004/06/wsn-WS-BaseNotification-1.2-draft-03.pdf %0D)

[**\[**](http://docs.oasis-open.org/wsn/2004/06/wsn-WS-BaseNotification-1.2-draft-03.pdf %0D)**WS-ResourceLifetime\]**
<http://docs.oasis-open.org/wsrf/2004/11/wsrf-WS-ResourceLifetime-1.2-draft-04.pdf>

**\[****WS-ResourceProperties\]**
<http://docs.oasis-open.org/wsrf/2004/11/wsrf-WS-ResourceProperties-1.2-draft-05.pdf>

**\[****WS-Security\]**
<http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0.pdf>

**\[****WS-Topics\]**
<http://docs.oasis-open.org/wsn/2004/06/wsn-WS-Topics-1.2-draft-01.pdf>

**\[****WS-I BP** **1.1\]**
<http://www.ws-i.org/Profiles/BasicProfile-1.1.html>

**\[WS-I** **BSP** **1.0\]**
<http://www.ws-i.org/Profiles/BasicSecurityProfile-1.0-2005-01-20.html>

**\[****XML-Infoset\]** <http://www.w3.org/TR/xml-infoset/>

**\[****XML-Names\]** http://www.w3.org/TR/REC-xml-names/

**\[****XPATH\]** http://www.w3.org/TR/xpath

# Non-Normative References {#non-normative-references .unnumbered}

**\[****SOAP 1.2\]** <http://www.w3.org/TR/soap12-part1/>

**\[****WSDL 2.0\]** <http://www.w3.org/TR/wsdl12/>

# KeyInformation Exchange Normative Description {#keyinformation-exchange-normative-description .AppendixHeading1}

## Introduction

This document is to define key information exchange for message level
security by using the Metadata element in the EndpointReference which is
defined in the latest WS-Addressing draft specification.

This document is intended to serve as a base input for the basic profile
discussion.

## Use cases

The followings are use cases that the profiles specified in the document
intend to cover.

-   When a client wants to send any encrypted message to a service, it
    will have to know the key associated with that service.

-   When a client wants to make a policy decision whether or not it
    wants a certain service to serve its request, it has to know the
    service\'s key-info.

## Namespaces

This appendix uses the following namespaces:

  ---------- -------------------------------------------------------------------------------------
  Prefix     Namespace

  wsa        <http://www.w3.org/2005/03/addressing>

  ds         [http://www.w3.org/2000/09/xmldsig#](http://www.w3.org/2000/09/xmldsig)

  wsse       <http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd>

  ogsa-bp    <http://docs.oasis-open.org/wsrf/2005/03/wsrf-WS-BaseFaults-1.2-draft-04.xsd>
  ---------- -------------------------------------------------------------------------------------

And this note also uses the following entity references to ease the
description of the URIs.

&wsse; the Namespace URI for Web Services Security v1.0

&ogsabp; the Namespace URI for OGSA Basic Profile 1.0

## Example

The following shows an example which the profile is intended to define.

(1) \<wsa:EndpointReference\>

(2) \<wsa:Address\>http://www.globus.org/some/path\</wsa:Address\>

(3) \<wsa:Metadata\>

(4) \<ogsabp:EndpointKeyInfo\>

(5) \<wsse:SecurityTokenReference wsse:Usage=\"&ogsabp;#signature\"\>

(6) \<wsse:Reference URI=\"#token1\"/\>

(7) \</wsse:SecurityTokenReference\>

(8) \<wsse:SecurityTokenReference wsse:Usage=\"&ogsabp;#encryption\"\>

(9) \<wsse:Embedded\>

(10) \<wsse:BinarySecurityToken ValueType=\"&wsse;X509PKIpathv1\"\>

(11) MIIC\.....

(12) \</wsse:BinarySecurityToken\>

(13) \</wsse:Embedded\>

(14) \</wsse:SecurityTokenReference\>

(15) \</ogsabp:EndpointKeyInfo\>

(16) \</wsa:Metadata\>

(17) \</wsa:EndpointReference\>

(01)-(17) An example wsa:EndointReference

(04)-(16) An example of ogsabp:EndpointKeyInfo elment is shown. The
actual key information contained in the ogsabp:EndpointKeyInfo element
is bound to the endpoint specified by the enclosing
wsa:EndpointReference.

(05)-(07) An example of actual key information is shown. The key is
expressed by using wsse:SecurityTokenReference and the wsse:Usage
attribute shows that the key shoud be used for signature. The key data
is referenced by the same document referece, \"#token1\".

(08)-(14) Another example of key information is shown. The key is also
expressed by using wsse:SecurityTokenReference, but the actual key data
is embbeded in the element as a wsse:BinarySecurityToken in
wsse:Embedded. And the usage of the key is specified as encryption by
the wsse:Usage attribute.

## Infoset

The following is the descriptions or definitions of the infosets refered
or defined in this note.

-   /wsa:EndpointReference/wsa:Metadata

> WS-Addressing defines optional wsa:Metadata element which is used to
> hold metadata that is relevant to the interaction with the endpoint.

-   /wsa:EndpointReference/wsa:Metadata/osgabp:EndpointKeyInfo/

> The ogsabp:EndpointKeyInfo is defined as a ds:KeyInfoType which is
> defined in the XML-Signture specification to contain generic key
> information. In this profile, the element is used to specify a key
> information which should be used to interact with the endpoint.

-   /wsa:EndpointReference/wsa:Metadata/ogsabp:EndpointKeyInfo/wsse:SecurityTokenReference

> Although the XML-Signature specification defines various types of
> elements which are intended to be used as a child element of
> ds:KeyInfoType element and the specification also allows the
> ds:KeyInfoType element to have arbitary types of elements in its
> content, this profile mandates the use of wsse:SecurityTokenReference
> elements under the ogsabp:EndpointKeyInfo element.

-   /wsa:EndpointReference/wsa:Metadata/ogsabp:EndpointKeyInfo/wsse:SecurityTokenReference/@wsse:Usage

> WS-Security defines this optional attribute which is used to type the
> usage of the wsse:SecurityTokenReference element.

This profile defines the following values for the \@wsse:Usage attribute
to specify the usage of the key referenced by the
wsse:SecurityTokenReference.

Value Usage

&ogsabp;#encryption Encryption key needed to interact with the

endpoint.

&ogsabp;#signature Signature verification key needed to interact

with the endpoint.

Absence of this attribute means that the key can be used for both
encryption and signature verification.

Implementations which create the key-info data MAY NOT set an
inconsitent value with the usage in the referenced key to this
\@wsse:Usage attribute. For example, if the KeyUsage certificate
extension of a X509 public key certificate is marked as CRITICAL and set
to Signing, then an implementation MAY NOT set &ogsabp;#encryption to
the \@wsse:Usage attribute. (Thus, in this case, the certificate cannot
be used as an encryption key.)

Implementations which detect an inconsistency between the value of
\@wsse:Usage attribute and the usage specified in the referenced key
itself MUST report an error and MAY NOT use the key for the usage
specified by the \@wsse:Usage attribute.

5\. Schema

The following schema fragment defines ogsabp:EndpointReferenceType

element defined in this profile.

\-\-\--

\<?xml version=\"1.0\" encoding=\"UTF-8\"?\>

\<xs:schema xmlns:xs=\"http://www.w3.org/2001/XMLSchema\"

xmlns:ogsabp=\"&ogsabp;\"

targetNamespace=\"&ogsabp;\"\>

\<!\-- definition f the EndpointKeyInfo element \--\>

\<xs:element name=\"EndpointKeyInfo\" type=\"ds:KeyInfoType\"/\>

\</xs:schema\>

\-\-\--

## Interoperability

To ensure the interoperability, a wsse:SecurityTokenReference element
MUST comform to the requirements defined in the section 4.2 of the WS-I
Basic Profile 1.0 document (SecurityTokenReferences).

To ensure the interoperability, if the wsse:BinarySecurityToken refers
to or embeds an X509 Certificate, the wsse:BinarySecurityToken MUST
comform to the requirements defined in the chapter 6 of the WS-I Basic
Profile 1.0 document (X509 Certificate Token Profile).

h

## Reference

WS-Addressing

Web Services Addressing 1.0 - Core

http://www.w3.org/TR/2005/WD-ws-addr-core-20050331/

XML-Signature

XML-Signature Syntax and Processing,

http://www.w3.org/TR/xmldsig-core/

Web Service Security

http://docs.oasis-open.org/wss/2004/01/

oasis-200401-wss-soap-message-security-1.0.pdf

WS-I Basic Security Profile

WS-I Basic Security Profile Working Groupd Draft

http://www.ws-i.org/Profiles/BasicSecurityProfile-1.0.html