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