Issue 12.
From: Don Schmidt
Sent: Tuesday, September 25, 2007 12:39 PM
To: wsfed@lists.oasis-open.org
Cc: Marc Goodner
Subject: FW: New Issue: Editorial changes to Section 2.7 Attributes,
Pseudonyms, and IP/STS Services and section 5 Attribute Service
PLEASE DO NOT REPLY TO THIS EMAIL OR START A DISCUSSISON
THREAD UNTIL THE ISSUE IS ASSIGNED A NUMBER.
The issues coordinators will notify the list when that has
occurred.
Title: Editorial changes to Section 2.7 Attributes,
Pseudonyms, and IP/STS Services and section 5 Attribute Service
Protocol: wsfed
ws-federation-1.2-spec-ed-01.doc:
http://www.oasis-open.org/apps/org/workgroup/wsfed/download.php/24422/ws-federation-1.2-spec-ed-01.doc
Artifact: spec
Type: editorial
[Issue Description]
The WS-Federation 1.1 specification is inconsistent with
respect to its recommendations about the potential interface to Attribute
Services. Section 2.7 specifically identifies the STS model as a baseline
interface to Attribute and Pseudonym services. Section 3.1.8 defined
federation metadata for advertising an Attribute Service instantiated as an
STS. However, section 5 states no interface is defined for an Attribute
Service. Besides being contradictory, the wording in section 5 ignores
the reusability of the WS-Trust STS service model and token issuance protocol
as a potential interface for advanced federation services that is clearly
recommended as an optional approach in other sections of the
specification.
[Discussion]
Section 2.7 Attributes, Pseudonyms,
and IP/STS Services states that Attribute and Pseudonym Services may be
integrated with, Security Token Services. The specification is clear that
the token issuance mechanism used for authenticating security principals
between federation partners can also be used for obtaining attributes,
including pseudonyms.
This specification extends the WS-Trust
model to allow attributes and pseudonyms to be integrated into the token
issuance mechanism to provide federated identity mapping and attribute
retrieval mechanisms, while protecting a principals’ privacy.
Figure 20 below illustrates the key aspects of this extended model:
Figure 20: Pseudonyms, Attributes and Token Issuance
Section 3.1.8 AttributeServiceEndpoint Element
defines federation metadata for advertising the transport address of an
Attribute Service instantiated as an STS from which attributes can be obtained
by requesting tokens.
The optional <fed:AttributeServiceEndpoint>
element allows a federation metadata
provider to specify the endpoint address of its attribute service which can be
referenced by federated partners when requesting tokens from it. This element
populates the [Federation Metadata] property. This is typically specified by
requestors and is a service-level statement. The schema for this optional
element is shown below. <fed:AttributeServiceEndpoint>
wsa:EndpointReferenceType </fed:AttributeServiceEndpoint> The content of this element is an endpoint reference
as defined by [WS-Addressing] providing a transport address for the issuer STS.
The endpoint reference MAY (and SHOULD if there is no expectation that the
policy is known a priori) include metadata for the STS endpoint or a
reference to an endpoint from where such metadata can be retrieved by a token
requestor (see [WS-Addressing] and [WS-MetadataExchange] for additional
details).
However, section 5 Attribute Service states that no
interface is defined for an Attribute Service.
Different
services MAY support different types of attribute services which MAY be
identified via policy by definition of new policy assertions indicating the
attribute service supported.
Each attribute store may support different subsets of the
functionality as described above. The store's policy indicates what
functionality it supports.
This
specification does not require or define a specific attribute service
definition or interface.
[Proposed
Resolution]
[section 2.7 existing text]
This specification extends the
WS-Trust model to allow attributes and pseudonyms to be integrated into the
token issuance mechanism to provide federated identity mapping and attribute
retrieval mechanisms, while protecting a principals’ privacy.
Figure 20 below illustrates the key aspects of this extended model:
[section
2.7 proposed text]
This specification extends the
WS-Trust model to allow attributes and pseudonyms to be integrated into the
token issuance mechanism to provide federated identity mapping and attribute
retrieval mechanisms, while protecting a principals’ privacy. Any attribute, including pseudonyms, MAY be provided by
an attribute or pseudonym service using the WS-Trust Security Token Service
interface and token issuance protocol. Additional protocols or
interfaces, especially for managing attributes and pseudonyms may be supported;
however, that is outside the scope of this specification. Figure
20 below illustrates the key aspects of this extended model:
[section
5 existing text]
Different services MAY support
different types of attribute services which MAY be identified via policy by
definition of new policy assertions indicating the attribute service
supported.
Each attribute store may support different subsets of the
functionality as described above. The store's policy indicates what
functionality it supports.
This specification does not require or define a specific
attribute service definition or interface.
[section
5 proposed text]
Different services MAY support
different types of attribute services which MAY be identified via policy by
definition of new policy assertions indicating the attribute service
supported.
Each attribute store may support different subsets of the
functionality as described above. The store's policy indicates what
functionality it supports.
This specification does not require or define a specific attribute service
definition or interface. However, as
indicated in sections 2.7 and 3.1.8, the WS-Trust Security Token Service
interface and token issuance protocol MAY be used as the interface to an
attribute service. Reusing an established service model and protocol
could simplify threat analysis and implementation of attribute services.
Don Schmidt
Principal Program Manager
Federated Identity
Microsoft Corporation