SAML V2.0 Metadata Extensions for Login and Discovery User Interface Version 1.0

Committee Specification Draft 03 /
Public Review Draft 02

10 January 2012

Specification URIs

This version:

http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-metadata-ui/v1.0/csprd02/sstc-saml-metadata-ui-v1.0-csprd02.odt (Authoritative)

http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-metadata-ui/v1.0/csprd02/sstc-saml-metadata-ui-v1.0-csprd02.html

http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-metadata-ui/v1.0/csprd02/sstc-saml-metadata-ui-v1.0-csprd02.pdf

Previous version:

http://www.oasis-open.org/committees/download.php/43924/sstc-saml-metadata-ui-v1.0-csprd01.zip

Latest version:

http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-metadata-ui/v1.0/sstc-saml-metadata-ui-v1.0.odt (Authoritative)

http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-metadata-ui/v1.0/sstc-saml-metadata-ui-v1.0.html

http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-metadata-ui/v1.0/sstc-saml-metadata-ui-v1.0.pdf

Technical Committee:

OASIS Security Services (SAML) TC

Chairs:

Thomas Hardjono (hardjono@mit.edu), M.I.T.
Nate Klingenstein (ndk@internet2.edu), Internet2

Editor:

Scott Cantor (cantor.2@osu.edu), Internet2

Additional artifacts:

This prose specification is one component of a Work Product which also includes:

Related work:

This specification defines extensions for use with:

Declared XML namespace:

Abstract:

This document defines a set of extensions to SAML metadata that provide information necessary for user agents to present effective user interfaces and, in the case of identity provider discovery, recommend appropriate choices to the user.

Status:

This document was last revised or approved by the OASIS Security Services (SAML) TC on the above date. The level of approval is also listed above. Check the “Latest version” location noted above for possible later revisions of this document.

Technical Committee members should send comments on this Work Product to the Technical Committee’s email list. Others should send comments to the Technical Committee by using the “Send A Comment” button on the Technical Committee’s web page at http://www.oasis-open.org/committees/security/.

For information on whether any patents have been disclosed that may be essential to implementing this Work Product, and any offers of patent licensing terms, please refer to the Intellectual Property Rights section of the Technical Committee web page (http://www.oasis-open.org/committees/security/ipr.php).

Citation format:

When referencing this Work Product the following citation format should be used:

[SAML-Metadata-UI-V1.0]

SAML V2.0 Metadata Extensions for Login and Discovery User Interface Version 1.0.
10 January 2012. OASIS Committee Specification Draft 03 / Public Review Draft 02.
http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-metadata-ui/v1.0/csprd02/sstc-saml-metadata-ui-v1.0-csprd02.html
.

Notices

Copyright © OASIS Open 2012. All Rights Reserved.

All capitalized terms in the following text have the meanings assigned to them in the OASIS Intellectual Property Rights Policy (the "OASIS IPR Policy"). The full Policy may be found at the OASIS website.

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 section are included on all such copies and derivative works. However, this document itself may not be modified in any way, including by removing the copyright notice or references to OASIS, except as needed for the purpose of developing any document or deliverable produced by an OASIS Technical Committee (in which case the rules applicable to copyrights, as set forth in the OASIS IPR Policy, 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 OWNERSHIP RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

OASIS requests that any OASIS Party or any other party that believes it has patent claims that would necessarily be infringed by implementations of this OASIS Committee Specification or OASIS Standard, to notify OASIS TC Administrator and provide an indication of its willingness to grant patent licenses to such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that produced this specification.

OASIS invites any party to contact the OASIS TC Administrator if it is aware of a claim of ownership of any patent claims that would necessarily be infringed by implementations of this specification by a patent holder that is not willing to provide a license to such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that produced this specification. OASIS may include such claims on its website, but disclaims any obligation to do so.

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' procedures with respect to rights in any document or deliverable produced by an OASIS Technical Committee can be found on 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 implementers or users of this OASIS Committee Specification or OASIS Standard, can be obtained from the OASIS TC Administrator. OASIS makes no representation that any information or list of intellectual property rights will at any time be complete, or that any claims in such list are, in fact, Essential Claims.

The name "OASIS" is a trademark of OASIS, the owner and developer of this specification, and should be used only to refer to the organization and its official outputs. OASIS welcomes reference to, and implementation and use of, specifications, while reserving the right to enforce its marks against misleading uses. Please see http://www.oasis-open.org/who/trademark.php for above guidance.



Table of Contents

1 Introduction 5

1.1 Terminology and Notation 5

1.2 Normative References 5

2 Metadata Extensions for Login and Discovery User Interface 7

2.1 User Interface Information 7

2.1.1 Element <mdui:UIInfo> 7

2.1.2 Element <mdui:DisplayName> 8

2.1.3 Element <mdui:Description> 8

2.1.4 Element <mdui:Keywords> 8

2.1.5 Element <mdui:Logo> 9

2.1.6 Element <mdui:InformationURL> 9

2.1.7 Element <mdui:PrivacyStatementURL> 9

2.2 Discovery Hinting Information 10

2.2.1 Element <mdui:DiscoHints> 10

2.2.2 Element <mdui:IPHint> 10

2.2.3 Element <mdui:DomainHint> 10

2.2.4 Element <mdui:GeolocationHint> 11

2.3 Security Considerations 11

2.4 Relationship with Existing Metadata Elements 11

2.4.1 <md:Organization> Elements 11

2.4.2 Service Name and Description 11

2.4.3 Suggested Precedence 12

2.5 Example 12

3 Conformance 14

3.1 SAML V2.0 Metadata Extensions for Login and Discovery User Interface Version 1.0 14

Appendix A Acknowledgments 15

Appendix B Revision History 16





1 Introduction

SAMLV2.0 metadata [SAML2Meta] provides a mechanism for expressing information necessary for SAML entities to successfully communicate with each other. However in most SAML profiles there is also a user agent involved, usually representing an actual person, that also participates in the profiled message exchanges. This document defines a set of extensions to metadata that provide information necessary for user agents to present effective user interfaces and, in the case of identity provider discovery, provide for recommendation of appropriate choices to the user.

There are existing, though incomplete, metadata elements that carry some of this information, but existing practice around their use is inconsistent, and defining extensions with more well-defined semantics is less disruptive to existing metadata deployments.

1.1 Terminology and Notation

The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this specification are to be interpreted as described in IETF RFC 2119. These keywords are thus capitalized when used to unambiguously specify requirements over protocol and application features and behavior that affect the interoperability and security of implementations. When these words are not capitalized, they are meant in their natural-language sense.

Conventional XML namespace prefixes are used throughout the listings in this specification to stand for their respective namespaces as follows, whether or not a namespace declaration is present in the example:

Prefix

XML Namespace

Comments

md:

urn:oasis:names:tc:SAML:2.0:metadata

This is the SAML V2.0 metadata namespace defined in the SAML V2.0 metadata specification [SAML2Meta].

mdui:

urn:oasis:names:tc:SAML:metadata:ui

This is the SAML V2.0 metadata extension namespace defined by this document and its accompanying schema.

xsd:

http://www.w3.org/2001/XMLSchema

This namespace is defined in the W3C XML Schema specification [Schema1]. In schema listings, this is the default namespace and no prefix is shown.

This specification uses the following typographical conventions in text: <ns:Element>, Attribute, Datatype, OtherCode.

This specification uses the following typographical conventions in XML listings:

Listings of XML schemas appear like this.


Listings of XML examples appear like this. These listings are non-normative.

1.2 Normative References

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

[RFC4632] V. Fuller et al. Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan. IETF RFC 4632, August 2006. http://www.ietf.org/rfc/rfc4632.txt

[RFC5870] A. Mayrhofer et al. A Uniform Resource Identifier for Geographic Locations ('geo' URI). IETF RFC 5870, June 2010. http://www.ietf.org/rfc/rfc5870.txt

[SAML2Errata] SAML V2.0 Errata. 1 December 2009. OASIS Approved Errata. http://docs.oasis-open.org/security/saml/v2.0/sstc-saml-approved-errata-2.0.pdf

[SAML2Meta] Metadata for the OASIS Security Assertion Markup Language (SAML) V2.0. 15 March 2005. OASIS Standard. http://docs.oasis-open.org/security/saml/v2.0/saml- metadata-2.0-os.pdf

[Schema1] H. S. Thompson et al. XML Schema Part 1: Structures. World Wide Web Consortium Recommendation, May 2001. http://www.w3.org/TR/2001/REC- xmlschema-1-20010502/

[Schema2] Paul V. Biron, Ashok Malhotra. XML Schema Part 2: Datatypes. World Wide Web Consortium Recommendation, May 2001. http://www.w3.org/TR/2001/REC- xmlschema-2-20010502/

2 Metadata Extensions for Login and Discovery User Interface

2.1 User Interface Information

The user interface extension elements are oriented towards the requirements of user agent presentation of entities represented by SAML metadata, typically as part of identity provider discovery or representing services requesting information from a user's identity provider. The specifics of such presentation and the use of the elements that follow is not in scope for this specification, but communities of use SHOULD establish guidelines and even prescriptive requirements to encourage consistency and understandability for users.

The <mdui:UIInfo> container element, defined below, MUST appear within the <md:Extensions> element of a role element (one whose type is based on md:RoleDescriptorType). The use of the <mdui:UIInfo> element, or any other element defined in this section, outside of that context is not defined by this specification.

This element, if it appears, MUST contain at least one child element.

Finally, this element MUST NOT appear more than once within a given <md:Extensions> element.

2.1.1 Element <mdui:UIInfo>

The <mdui:UIInfo> element contains information which pertains to (but is not specifically limited to) the creation of user interfaces for tasks such as identity provider selection/discovery, user authentication, attribute release consent, etc.

This element contains any number of the following elements, in any order:

<mdui:DisplayName>

A localized name for the entity operating in the containing role.

<mdui:Description>

A localized description of the entity operating in the containing role.

<mdui:Keywords>

Localized search keywords, tags, categories, or labels for the containing role.

<mdui:Logo>

A localized logo image for the entity operating in the containing role.

<mdui:InformationURL>

A URL to localized information about the entity operating in the containing role.

<mdui:PrivacyStatementURL>

A URL to localized information about the privacy practices of the entity operating in the containing role.

In addition, this element MAY contain an arbitrary number of extension elements from other namespaces, the definitions/semantics of which must be supplied elsewhere.

The schema for the <mdui:UIInfo> element, and its corresponding mdui:UIInfoType complex type, is as follows:

<element name="UIInfo" type="mdui:UIInfoType"/>

<complexType name="UIInfoType">

<choice minOccurs="0" maxOccurs="unbounded">

<element ref="mdui:DisplayName"/>

<element ref="mdui:Description"/>

<element ref="mdui:Keywords"/>

<element ref="mdui:Logo"/>

<element ref="mdui:InformationURL"/>

<element ref="mdui:PrivacyStatementURL"/>

<any namespace="##other" processContents="lax"/>

</choice>

</complexType>

2.1.2 Element <mdui:DisplayName>

The <mdui:DisplayName> element specifies a localized name fit for display to users. Such names are meant to allow a user to distinguish and identify the entity acting in a particular role. The content of this element should be suitable for use in constructing accessible user interfaces for those with disabilities.

There MUST NOT be more than one <mdui:DisplayName> element with the same xml:lang attribute value within a single role descriptor.

The schema for the <mdui:DisplayName> element is as follows:

<element name="DisplayName" type="md:localizedNameType"/>

2.1.3 Element <mdui:Description>

The <mdui:Description> element specifies a brief, localized description fit for display to users. In the case of an <md:SPSSODescriptor> role, this SHOULD be a description of the service being offered. In the case of an <md:IDPSSODescriptor> role this SHOULD include a description of the user community serviced.

In all cases this text MUST be standalone, meaning it is not to be used as a template requiring additional text (e.g., "This service offers $description").

There MUST NOT be more than one <mdui:Description> element with the same xml:lang attribute value within a single role descriptor.

The schema for the <mdui:Description> element is as follows:

<element name="Description" type="md:localizedNameType"/>

2.1.4 Element <mdui:Keywords>

The <mdui:Keywords> element specifies a list of localized search keywords, tags, categories, or labels that apply to the containing role. This element extends the mdui:listOfStrings schema type with the following attribute:

xml:lang [Required]

Language specifier.

The content of this element is a "list" of strings in the XML Schema [Schema2] sense, which means the keyword strings are space-delimited. Spaces within individual keywords are encoded with a “plus” (+) character; as a consequence, keywords may not contain that character.

There MUST NOT be more than one <mdui:Keywords> element with the same xml:lang attribute value within a single role descriptor.

The schema for the <mdui:Keywords> element, and its corresponding mdui:KeywordsType complex type, is as follows:

<element name="Keywords" type="mdui:KeywordsType"/>

<complexType name="KeywordsType">

<simpleContent>

<extension base="mdui:listOfStrings">

<attribute ref="xml:lang" use="required"/>

</extension>

</simpleContent>

</complexType>

<simpleType name="listOfStrings">

<list itemType="string"/>

</simpleType>

2.1.5 Element <mdui:Logo>

The <mdui:Logo> element specifies the external location of a localized logo fit for display to users. This element extends the anyURI schema type with the following attributes:

height [Required]

The rendered height of the logo measured in pixels.

width [Required]

The rendered width of the logo measured in pixels.

xml:lang

Optional language specifier.

In order to facilitate the usage of logos within a user interface, logos SHOULD:

The order of logo elements is not significant, and a consumer MAY select any logo that meets its presentation and internationalization requirements. Communities of use SHOULD establish guidelines or requirements for logo size, aspect ratio, etc. to ensure consistency. If logos without an xml:lang attribute are present, then they SHOULD be considered the default logos for use when logos in the user's preferred language are not available.

Note that while vector graphic formats may be renderable at many sizes, the height and width attributes remain mandatory to allow consumers that lack intelligence regarding image processing to locate images suitable for particular sizes. The same image MAY be specified with multiple sizes when appropriate.

The schema for the <mdui:Logo> element, and its corresponding mdui:LogoType complex type, is as follows:

<element name="Logo" type="mdui:LogoType"/>

<complexType name="LogoType">

<simpleContent>

<extension base="anyURI">

<attribute name="height" type="positiveInteger" use="required"/>

<attribute name="width" type="positiveInteger" use="required"/>

<attribute ref="xml:lang"/>

</extension>

</simpleContent>

</complexType>

2.1.6 Element <mdui:InformationURL>

The <mdui:InformationURL> specifies an external location for localized information about the entity acting in a given role meant to be viewed by users. The content found at the URL SHOULD provide more complete information than what would be provided by the <mdui:Description> element.

There MUST NOT be more than one <mdui:InformationURL> element with the same xml:lang attribute value within a single role descriptor.

The schema for the <mdui:InformationURL> element is as follows:

<element name="InformationURL" type="md:localizedURIType"/>

2.1.7 Element <mdui:PrivacyStatementURL>

The <mdui:PrivacyStatementURL> specifies an external location for localized privacy statements. Such statements are meant to provide a user with information about how information will be used and managed by the entity acting in a given role.

There MUST NOT be more than one <mdui:PrivacyStatementURL> element with the same xml:lang attribute value within a single role descriptor.

The schema for the <mdui:PrivacyStatementURL> element is as follows:

<element name="PrivacyStatementURL" type="md:localizedURIType"/>

2.2 Discovery Hinting Information

The discovery hinting extension elements provide information that hints at the identity provider with which a user is associated. A server-side selection mechanism could leverage such hints in conjunction with client-supplied information to adjust likely choices.

Information provided by the content of this element is meant only as a hint and SHOULD NOT be used to definitively select an identity provider without user intervention or confirmation. As a consequence, hints are inappropriate to use in conjunction with discovery protocols or protocol features that would prevent user interaction.

The <mdui:DiscoHints> container element, defined below, MUST appear within the <md:Extensions> element of an <md:IDPSSODescriptor> element. The use of the <mdui:DiscoHints> element, or any other element defined in this section, outside of that context is not defined by this specification.

This element, if it appears, MUST contain at least one child element.

Finally, this element MUST NOT appear more than once within a given <md:Extensions> element.

2.2.1 Element <mdui:DiscoHints>

The <mdui:DiscoHints> element contains information that may be used by an identity provider selection/discovery service as hints in determining with which identity provider(s) the user may be associated.

This element contains any number of the following elements, in any order:

<mdui:IPHint>

IP address blocks associated with, or serviced by, the entity operating in the containing role.

<mdui:DomainHint>

DNS domain names associated with, or serviced by, the entity operating in the containing role.

<mdui:GeolocationHint>

Geographic coordinates associated with, or serviced by, the entity operating in the containing role.

In addition, this element MAY contain an arbitrary number of extension elements from other namespaces, the definitions/semantics of which must be supplied elsewhere.

The schema for the <mdui:DiscoHints> element, and its corresponding mdui:DiscoHintsType complex type, is as follows:

<element name="DiscoHints" type="mdui:DiscoHintsType"/>

<complexType name="DiscoHintsType">

<choice minOccurs="0" maxOccurs="unbounded">

<element ref="mdui:IPHint"/>

<element ref="mdui:DomainHint"/>

<element ref="mdui:GeolocationHint"/>

<any namespace="##other" processContents="lax"/>

</choice>

</complexType>

2.2.2 Element <mdui:IPHint>

The <mdui:IPHint> element specifies an [RFC4632] block associated with, or serviced by, the entity. Both IPv4 and IPv6 CIDR blocks MUST be supported.

The schema for the <mdui:IPHint> element is as follows:

<element name="IPHint" type="string"/>

2.2.3 Element <mdui:DomainHint>

The <mdui:DomainHint> element specifies a DNS domain associated with, or serviced by, the entity.

The schema for the <mdui:DomainHint> element is as follows:

<element name="DomainHint" type="string"/>

2.2.4 Element <mdui:GeolocationHint>

The <mdui:GeolocationHint> element specifies a set of geographic coordinates associated with, or serviced by, the entity. Coordinates are given in URI form using the geo URI scheme [RFC5870].

The schema for the <mdui:GeolocationHint> element is as follows:

<element name="GeolocationHint" type="anyURI"/>

2.3 Security Considerations

The information contained in these extensions, as well as the content identified by various URLs, is intended for the construction of user interfaces. As such, special consideration by implementers and deployers is warranted.

Any URLs MUST be carefully sanitized and encoded to protect against cross-site scripting and related vulnerabilities. Schemes other than “https”, “http”, or “data” SHOULD NOT be used.

Since it is generally impractical to guarantee the continued safety of content behind a particular URL, the use of “https” URLs is RECOMMENDED, and control over the URLs in question must be carefully established by the publisher of metadata containing these extensions. Consumers of metadata using these extensions to construct UIs must ensure the provenance of metadata and that the processes by which the extensions are managed by the publisher are sufficiently sound.

This is particularly relevant for the <mdui:Logo> element, since such URLs are often dereferenced by the user agent without intervention. Where practical, the use of server-side image processing may enable a higher degree of safety and control over the presentation of images than direct embedding of links to logos.

2.4 Relationship with Existing Metadata Elements

2.4.1 <md:Organization> Elements

SAML metadata defines localized organizational names, display names, and URLs at both the entity and role level. These elements are meant to reflect information about the organization that “owns" or operates a particular entity. To date, most known identity provider discovery interfaces have relied on entity-level <md:OrganizationDisplayName> element content. Some applications will also display the organization name for service providers as a means of identifying the service.

However, such usage is based on two implicit assumptions:

There are many cases, however, where one or both of these assumption are not true. An example conflicting with the first assumption may be Virginia Polytechnic Institute and State University, which the world knows as "Virginia Tech". An example that conflicts with both assumptions might be a third-party hosting service. Its name would not be recognized by any user and it could operate many entities at any given time.

However, the organizational display name may still be useful, for example within “owned by..." or “operated by..." statements.

2.4.2 Service Name and Description

Entities with a <md:SPSSODescriptor> role may optionally include one or more <md:AttributeConsumingService> elements which in turn contain <md:ServiceName> and <md:ServiceDescription> elements. These elements are normally used to expose the attribute requirements for various service “levels" and to associate certain names and descriptions with them.

The following issues make these elements inappropriate for carrying a general display name and description for the service:

2.4.3 Suggested Precedence

Implementations that rely on display name information SHOULD rely on elements in the following order of preference:

As a consequence, entities may rely on the existing <md:ServiceName> (or where appropriate the <md:ServiceDescription>) element by omitting the <mdui:DisplayName> (or <mdui:Description>) element from their metadata.

Note that when multiple <md:AttributeConsumingService> elements are used, some identity or discovery protocols may lack the ability to signal which of the multiple elements is relevant to a request. In such deployments, limiting the cardinality to a single element or requiring the use of the <mdui:DisplayName> element may be necessary.

Implementations MAY support the use of <md:OrganizationDisplayName>, particularly as a migration strategy, but this is not recommend this as a general practice.

2.5 Example

An elided example follows.

<EntityDescriptor entityID="https://idp.switch.ch/idp/shibboleth"

xmlns="urn:oasis:names:tc:SAML:2.0:metadata"

xmlns:mdui="urn:oasis:names:tc:SAML:metadata:ui">


<IDPSSODescriptor

protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">

<Extensions>

<mdui:UIInfo>


<mdui:DisplayName xml:lang="en">SWITCH</mdui:DisplayName>

<mdui:DisplayName xml:lang="de">SWITCH</mdui:DisplayName>

<mdui:Description xml:lang="en">

Switzerland's national research and eduction network.

</mdui:Description>

<mdui:Description xml:lang="de">

Das schweizerische Hochschul- und Forschungsnetzwerk.

</mdui:Description>


<mdui:Logo height="16" width="16">

https://switch.ch/resources/images/smalllogo.png

</mdui:Logo>

<mdui:Logo height="97" width="172">

https://switch.ch/resources/images/logo.png

</mdui:Logo>


<mdui:InformationURL xml:lang="en">

http://switch.ch

</mdui:InformationURL>

<mdui:InformationURL xml:lang="de">

http://switch.ch/de

</mdui:InformationURL>


</mdui:UIInfo>


<mdui:DiscoHints>


<mdui:IPHint>130.59.0.0/16</mdui:IPHint>

<mdui:IPHint>2001:620::0/96</mdui:IPHint>


<mdui:DomainHint>switch.ch</mdui:DomainHint>


<mdui:GeolocationHint>geo:47.37328,8.531126</mdui:GeolocationHint>


</mdui:DiscoHints>

</Extensions>


<!-- other role-level elements -->

</IDPSSODescriptor>

</EntityDescriptor>

3 Conformance

3.1 SAML V2.0 Metadata Extensions for Login and Discovery User Interface Version 1.0

A metadata producer conforms to this profile if it has the ability to produce metadata in accordance with sections 2.1 and 2.2.

A metadata consumer conforms to this profile if it can consume extended metadata produced in accordance with sections 2.1 and 2.2.

An identity provider discovery service or agent conforms to this profile if it has the ability to consume and utilize extended metadata produced in accordance with sections 2.1, 2.2, and 2.4.3.

Appendix A Acknowledgments

The editor would like to acknowledge the contributions of the OASIS Security Services Technical Committee, whose voting members at the time of publication were:

The editor would also like to acknowledge the following contributors:

Appendix B Revision History

Working Draft 10:

Working Draft 09:

Working Draft 08:

Working Draft 07:

Working Draft 06:

Working Draft 05:

Working Draft 04:

Working Draft 03:

Working Draft 02:

Working Draft 01

Presubmission Changes:

Changes to Draft 03:

Changes to Draft 02:

Changes to Draft 01:

sstc-saml-metadata-ui-v1.0-csprd02 10 January 2012

Standards Track Work Product Copyright © OASIS Open 2012. All Rights Reserved. Page 17 of 17