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: Indicating functionally equivalent service endpoints in Federation Metadata
Protocol: wsfed
Artifact: spec
Type: design
[Issue Description]
Section 3, Federation Metadata, defines five different elements for specifying the endpoint address of a particular type of federation service: TokenIssuerEndpoint, PseudonymServiceEndpoint, AttributeServiceEndpoint, SingleSignOutSubscriptionEndpoint,
SingleSignoutNotificationEndpoint
All five elements are currently defined as containing a single endpoint reference. If multiple elements of the same type appear in a Federation Metadata section there is no way to determine which endpoint elements contain functionally distinct endpoint
references for different services with different capabilities and which endpoint elements contain functionally equivalent endpoint references for a single service, or for a set of logically related services with the same capabilities.
Therefore, Relying Parties and client requestors may have to query numerous endpoint references -- potentially retrieving multiple copies of additional metadata (e.g WSDL or Security Policy) for a service that is not appropriate -- before they locate the
service with the desired capabilities.
[Discussion]
There are several, common scenarios which result in a single logical service being accessible via multiple endpoints.
- It is common practice for a service provider to offer the same service at different physical endpoints [sometimes in geographically distributed locations] to improve system robustness or optimize network performance.
- Even if the service runs on a single server, there still may be multiple endpoint references. For example there might be multiple URIs for a particular server, or the server might be multi-homed or deployed as multiple clustered nodes with distinct domain
names.
- Endpoint references might have different transport security properties but still point to functionally equivalent instances of a single logical service.
[Proposed Resolution]
Modify each of the service endpoint elements in Sections 3.1.6, 3.1.7, 3.1.8, 3.1.9 and 3.1.10 to be plural (eg AttributeServiceEndpoints) and allow the element to contain one, or more, endpoint references. A service provider MUST only include endpoint
references in a single element that point to the same service instance, or functionally equivalent instances of the same logical service.
[Proposed Text Changes for section 3.1.6]
3.1.6 TokenIssuerEndpoints Element
The optional <fed:TokenIssuerEndpoints>
element allows a federation metadata provider to specify the endpoint address of a trusted STS (or addresses of functionally equivalent STSs) which can be used by federated partners when requesting
tokens to be consumed by the metadata provider. This element populates the [Federation Metadata] property. This is specified by any Relying Party (e.g. token issuers, security token services, and service providers). This is typically a service-level statement
but can be an endpoint-level statement. This element MAY be specified even if the <fed:TokenIssuerName> element is specified.
The schema for this optional element is shown below.
<fed:TokenIssuerEndpoints>
wsa:EndpointReferenceType+
</fed:TokenIssuerEndpoints>
The content of this element is one, or more, an endpoint references as defined by [WS-Addressing]
that identifies an endpoint providing a transport address for the issuer STS (or functionally equivalent STSn endpoints). Each 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).
This element allows attributes to be added so long as they do not alter the semantics defined in this specification.
It should be noted that this element MAY occur multiple times indicating distinct different services with different
capabilities. Service providers MUST include or different functionally equivalent endpoints – different endpoint references for at
a common single service, or for a set of logically equivalent services – in a single <fed:TokenIssuerEndpoints>
element.
The following example illustrates using this optional element to specify an endpoint address for the token issuing STS of the federating organization.
<fed:TokenIssuerEndpoints>
</fed:TokenIssuerEndpoints>
[Proposed Text Changes for section 3.1.7]
3.1.7 PseudonymServiceEndpoints Element
The optional <fed:PseudonymServiceEndpoints>
element allows a federation metadata provider to specify the endpoint address of its pseudonym service (or addresses for functionally equivalent pseudonym services) which can be referenced by federated partners when requesting tokens
from it. When present, this indicates that services SHOULD use the pseudonym service to map identities to local names as the identities MAY vary across invocations. This element populates the [Federation Metadata] property. This is typically specified by
token issuers and security token services. This is typically a service-level statement but can be an endpoint-level statement.
The schema for this optional element is shown below.
<fed:PseudonymServiceEndpoints>
wsa:EndpointReferenceType+
</fed:PseudonymServiceEndpoints>
The content of this element is one, or more, an endpoint references as defined by [WS-Addressing]
providing a transport address for the an STS interface to the pseudonym service (or functionally equivalent pseudonym service endpoints). Each 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).
This element allows attributes to be added so long as they do not alter the semantics defined in this specification.
It should be noted that this element MAY occur multiple times indicating distinct different services with different
capabilities. Service providers MUST include or different functionally equivalent endpoints – different endpoint references for at
a common single service, or for a set of logically equivalent services – in a single <fed:PseudonymServiceEndpoints>
element.
The following example illustrates using this optional element to specify an endpoint address for the pseudonym service of the federating organization.
<fed:PseudonymServiceEndpoints>
</fed:PseudonymServiceEndpoints>
[Proposed Text Changes for section 3.1.8]
3.1.8 AttributeServiceEndpoints Element
The optional <fed:AttributeServiceEndpoints>
element allows a federation metadata provider to specify the endpoint address of its attribute service (or addresses for functionally equivalent attribute services) 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:AttributeServiceEndpoints>
wsa:EndpointReferenceType+
</fed:AttributeServiceEndpoints>
The content of this element is one, or more, an endpoint references as defined by [WS-Addressing]
providing a transport address for the issuer an STS interface to the attribute service (or functionally equivalent attribute service
endpoints). Each 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).
This element allows attributes to be added so long as they do not alter the semantics defined in this specification.
It should be noted that this element MAY occur multiple times indicating distinct different services with different
capabilities. Service providers MUST include or different functionally equivalent endpoints – different endpoint references for at
a common single service, or for a set of logically equivalent services – in a single <fed:AttributeServiceEndpoints>
element.
The following example illustrates using this optional element to specify an endpoint address for the attribute service of the federating organization.
<fed:AttributeServiceEndpoints>
</fed:AttributeServiceEndpoints>
[Proposed Text Changes for section 3.1.9]
3.1.9 SingleSignOutSubscripionEndpoints Element
The optional <fed:SingleSignOutSubscriptionEndpoints>
element allows a federation metadata provider to specify the endpoint address of its subscription service (or addresses for functionally equivalent suscription services) which can be used to subscribe to federated sign-out messages.
This element populates the [Federation Metadata] property. This is typically specified by token issuers and security token services. This is typically a service-level statement but can be an endpoint-level statement.
The schema for this optional element is shown below.
<fed:SingleSignOutSubscriptionEndpoints>
wsa:EndpointReferenceType+
</fed:SingleSignOutSubscriptionEndpoints>
The content of this element is one, or more, an endpoint references as defined by [WS-Addressing]
providing a transport address for the subscription manager (or functionally equivalent subscription service endpoints).
This element allows attributes to be added so long as they do not alter the semantics defined in this specification.
[Proposed Text Changes for section 3.1.10]
3.1.10 SingleSignOutNotificationEndpoints Element
Services MAY subscribe for sign-out notifications however clients MAY also push notifications to services. The optional <fed:SingleSignOutNotificationEndpoints>
element allows a federation metadata provider to specify the endpoint address (or functionally equivalent addresses) to which push notifications of sign-out are to be sent. This element populates the [Federation Metadata] property.
This is typically specified by service providers and security token services. This is typically a service-level statement but can be an endpoint-level statement.
The schema for this optional element is shown below.
<fed:SingleSignOutNotificationEndpoints>
wsa:EndpointReferenceType+
</fed:SingleSignOutNotificationEndpoints>
The content of this element is one, or more, an endpoint references as defined by [WS-Addressing]
providing a transport address for the notification service subscription manager (or functionally equivalent notification service endpoints).
This element allows attributes to be added so long as they do not alter the semantics defined in this specification.
Don Schmidt
Principal Program Manager
Microsoft Corporation