Confidential – PartnerJuly 17, 2009

DTV-IdP Authorization

Authentication Specification


Published by

Sep 15, 2009

Version 0.1

Document Identifier:

DTV-IdP-Authentication-ExternalIntegration-0.1

DIRECTV Confidential
This document contains proprietary information and except with written permission of DIRECTV such information shall not be published and this document shall not be duplicated or distributed in whole or part.
REVISION HISTORY
Date / Author / Description of Change
Kapil Chaudry, Jin Chung, Uday Ravuri / Initial release
Deena Gurajala / Added support for HTTP Redirect/HTTP POST Binding as per SAML 2.0 Specification

Table of contents

1 Introduction

Disclaimer

2 Overview

2.1 Authentication/Authorization for Service Providers

3 Authentication

3.1 The Authentication Process

3.2 SAML based Authentication

3.3 Authentication Request

3.3.1 Sample Request Details

3.3.2 Authentication Response

4 SP features required for Authentication

5 Common Domain Cookie Support

7 Error Codes

8 References

DirecTV IdP Authentication Specification

DIRECTV Confidential

Do not copy without prior DIRECTV authorization


Confidential – PartnerJuly 17, 2009

1 Introduction

This document describes the process to interface withDTV-IdPto access Directv’s services.It is intended for Partners (Service Providers) who want their web-based applications to access Directv’s services on behalf of users, using DTV-IdP’s Authentication and Authorization services.

Disclaimer

DIRECTV makes no representations, express or implied, that use of the technologies described in this specification will not infringe patents, copyrights, or other intellectual property rights of third parties. Nothing in this specification should be construed as granting permission to use any of the technologies described. Anyone planning to make use of technology covered by the intellectual property rights of others should first obtain permission from the holder(s) of the rights.

This specification is subject to change without notice. DIRECTV does not accept any responsibility whatsoever for damages or liability, direct or consequential, which may result from use of this specification or any related discussions.

2 Overview

DTV-IdP is a standalone SAML 2.0 compliant Identity Provider solution which bundles all the security and identity related components necessary to enable partners to communicate with service providers native to Directv security domain. We use an event-based model to receive process and respond to HTTP and SOAP-based messages and manage connections in Single Sign On fashion (SSO).

2.1 Authentication/Authorization for Service Providers

Every time a consumer tries to access web content through a service providers that requires the user to have a Directv account , it has to first authenticate the user against the DTV-IdP’s Authentication service. Upon successful authentication, the web application receives a SAML assertion from the DTV-IDPAuthentication service. If the Service Provider (SP) needs explicit authorization for the user requested resource, then an authorization request containing a SAML Authorization Decision Query is sent via SOAP over HTTPS to the DTV-IdP Authorization service.

The following diagram illustrates this process.

Figure 1.1 Authn/Authz for SPs

3Authentication

Web applications that need to access services hosted by Directv or protected by the user’s Directv account can do so using DTV-IdP’s Authentication service. Before using, verify that the Directv’s service to be accessed supports the DTV-IdP’s Authentication service.

3.1The Authentication Process

There are three entities involved in a typical Authentication Service Providers, DTV- IdP, and the user. The following diagram illustrates the sequence:

Fig 1.0 DTV-IdP Authentication Flow

The flow starts when the user attempts to access a resource on Service provider’s site that is protected by Directv specific login credentials.

  1. The Service Provider does not have a valid Directv Token for the user in the corresponding security context.
  2. Service provider identifies the ID provider for user Authentication (SP can use DirecTV IDP Discovery service).
  3. The SP sends a SAML <AuthnRequest> using HTTP POST or HTTP Redirect bindingto DTV-IdP’s Authentication servervia HTTPS. Within the request is the information from Step 3 referenced as additional attributes.
  4. The DIRECTV IDP will validate the message format for required data and digital signature. It also validate the age of the request. If it is older than 5 seconds (it is configurable), we will reject the message. The age of the message is determined from the value of attribute IssueInstant of the AuthnnRequest Element.
  5. The DIRECTV IDP Authentication service tries to resolve any Common Domain Cookie specific info from Request.
  6. If the Common Domain Cookie information is resolved within the security context of DTV-IdP, then a corresponding SAML Assertion with a SPID, Token (Site Specific)and UUID is sent to the Service Provider. DTV-IDP Authentication Service also calls Cookie Writer Service to set/update the common domain cookie.
  7. If the Common Domain Cookie information can not be resolved within the security context of DTV-IDP or if it is invalid, then the user is redirected to the login page.
  8. This login page prompts the user to enter their Directv specific login credentials. If the user enters valid login credentials and signs in, the user is granted access.
  9. If the user is denied access, they are directed to a Directv login page rather than back to the Service Provider (TBD).
  10. When the useris granted access (i.e. successful login), the Authentication servicewill call Common Domain Writing Service to create/update the Common Domain Cookie (CDC) in the user’s browser and then redirects the user back to the SP’s web site.Note: CDC support is explained in Section 4.
  11. The authorization flow starts after this if the SP’s web application needs explicit authorization for the user requested resource.
  12. For the detailed flow please refer to the diagram below.

3.2SAML based Authentication

The Authentication API exposed by the DTV-IdP’s Authentication service is based on the SAML 2.0 standard; specifically, on the "Web Browser SSO Profile."

The SAML profiles and bindings described below are derived from the SAML specifications detailed in the following open standard documentations:

DTV-IdP uses the following SAML profile for its Authentication mechanism:

  • SP-initiated Single Sign On (SSO) using a POST/Redirectbinding for theSP-to-IdP<AuthnRequest> message and POST/Redirect binding fortheIdP-to-SP<Response> message.

Note:

  • All Requests to DTV-IdP must be signed using certificates that are pre-registered between DTV-IdP and the Service Provider.
  • All Responses originating from DTV-IdP to the Service Provider are also signed in a similar fashion.

3.3Authentication Request

The format of the <AuthnRequest> is part of the SAML protocol schema defined in saml-schema-protocol-2.0.xsd. The Service Provider’s web application makes a request to DTV-IdP’s Authentication service using HTTP POST or HTTP Redirect Binding as defined in Step 1 of Authentication process above. The end-point (URL) is defined below:

(ThisURL is just an example)

Note:

  1. The <AuthnRequest> MUST be signed by the Service Provider.
  2. All communication with DTV-IdP takes place over SSL 3.0/TLS1.0 compatible Https.

The expected parameters are:

Parameter / Description
SAMLRequest / (required)(case sensitive)(value is base64encoded)Corresponds to SAML <AuthnRequest> message of Web Browser SSO profile which makes use of the "Authentication Request Protocol".
The XSD is based on saml-schema-protocol-2.0.xsd
RelayState / (optional) URL containing current state information if any.
token / (Optional) Used by DTV to verify whether user has already authenticated with other SP.

3.3.1 Sample Request Details

The URL for the service has not yet been deployed but will follow this convention:

HTTP Redirect Binding:

SAMLAuthRequest?SAMLRequest=BASE64URLENCODEDELEMENT&RelayState=

The request parameter ‘token’ is common domain cookie token. It is part of IDP Authentication Service URL. This URL set by common domain cookie writer. Token attribute is an optional parameter. If it is present Authentication Service will validate the token and issue an assertion containing site specific token. If token attribute is not present or not valid, we redirect the user to log in page and ask them to provide credentials. After successful authentication, Authentication Service will issue an assertion containing site specific token.

Format of BASE64URLENCODEDELEMENT (source: saml-schema-protocol-2.0.xsd):

<element name="AuthnRequest" type="samlp:AuthnRequestType"/>

<complexType name="AuthnRequestType">

<complexContent>

<extension base="samlp:RequestAbstractType">

<sequence>

<element ref="saml:Subject" minOccurs="0"/>

<element ref="samlp:NameIDPolicy" minOccurs="0"/>

<element ref="saml:Conditions" minOccurs="0"/>

<element ref="samlp:RequestedAuthnContext" minOccurs="0"/>

<element ref="samlp:Scoping" minOccurs="0"/>

</sequence>

<attribute name="ForceAuthn" type="boolean" use="optional"/>

<attribute name="IsPassive" type="boolean" use="optional"/>

<attribute name="ProtocolBinding" type="anyURI" use="optional"/>

<attribute name="AssertionConsumerServiceIndex" type="unsignedShort" use="optional"/>

<attribute name="AssertionConsumerServiceURL" type="anyURI" use="optional"/>

<attribute name="AttributeConsumingServiceIndex" type="unsignedShort" use="optional"/>

<attribute name="ProviderName" type="string" use="optional"/>

</extension>

</complexContent>

</complexType>

Example:

nVNta9swEP4rQv1sS3ZamojYJawMwpJS6nSMfgmudInVWZInyUnz7ycnTknLGsqMwBx397zcSeOb%0AV1WjDVgnjc5wElOMQHMjpF5n%2BHHxPRrim3zsSlU3bNL6Sj%2FAnxacR6FPO7ZPZLi1mpnSScd0qcAx%0Az1kxmc9YGlPWWOMNNzVGE%2BfA%2BkD0zWjXKrAF2I3k8Pgwy3DlfcMISWicDuJkmIYfG9IhJcJvIima%0AiNcStCf80Dtx1muMprcZXiol0jQNgXMtTLXzpfYZTikdRd25XCTXbDBiyVV8Ta%2BeMPp5tBvk4YM5%0Atu%2B1J67OmyqPVjAq7u%2Bt2UgBohNDD1%2BK868aGpMTAb2aon1%2BAe7%2FQ857gDDolbSq7FJoDr4y4p9A%0AHQZXrDK1ABuZVfQbdmegbktf9tpenXzb3Xa7jbeD2Ng1CcNPyK%2F5rOAVqDKS%2B6VwwCjUM79rIMN7%0A8B%2Bwm%2BqV%2BQi%2BCBWBX7hjQc8m3CdklNARCTXCyfXFW%2Bdd8Jf7cFuXh1kvm%2Fa5ljyYG5OTimPQEeX9%0AOj5xfSb9IdWH719N%2Fhc%3D&RelayState=http%3A%2F%2Ftest.com%2Fvideo&SigAlg=rsa-sha1&Signature=NJsrNfkWl3JehGy6avRVfPul3ItU8Kt1uEyEBOjqjiyQ94gHaahFzaldA3S%2B1CqsypToPG7QqA0p%0AQKcgt5Uc2YaY8BiKyCLhQm8qAHbsDOqc074qDnZFAc2sEZSSyy3j34eUsBYEqBz7Rqz22GH9dAH7%0Ap4XanaPP1SjtP0au610%3D

Sample SAMLRequest element prior to base64 encoding:

<?xml version="1.0" encoding="UTF-8"?<samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" AssertionConsumerServiceURL=" ID="_mmd222" IssueInstant="2009-09-04T17:39:15.705Z" Version="2.0">

<saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" SPProvidedID="00000002">

<saml:Subject xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">

<saml:SubjectConfirmation Method="urn:oasis:names:tc:2.0:cm:holder-of-key">

<saml:SubjectConfirmationData xmlns:xsi=" xsi:type="saml:KeyInfoConfirmationDataType">

<ds:KeyInfo xmlns:ds="

<ds:KeyName>test_server_publickey</ds:KeyName>

</ds:KeyInfo>

</saml:SubjectConfirmationData>

</saml:SubjectConfirmation>

</saml:Subject>

</samlp:AuthnRequest>

The service provider has to send site id as value of SPProviderId attribute of <SAML Issuer> Element. If Service provider does not have site ID yet, Service provider has to register with DirecTV and receive a site ID. It is a mandatory attribute for us.

3.3.2Authentication Response

The response from DTV-IdP is a Signed SAML Assertion contains two (2) attributes.

The SAML assertion attributes:

  1. Token the DTV-IdP specific unique key for the user as an attribute with name as eToken
  2. SP-ID the SiteId (DTV-IdP’s internal representation of the Service Provider) as an attribute with name the as SPID
  3. UUID the Directv Account Id (DTV-IdP’s internal representation of the User). It will be sent as the nameId element under Subject.

The validity of the Token and its features are mentioned in the Token Validity Section below.

Sample Response URL

Sample <RESPONSE> SAMLResponse=zVXbcqJAEP0Va%2FbRUm5qhBJSKjFLDMYL3vKS4jIoK8wgM4jm63dQScUkZvO4FC893af7nEPX0Lrd%0AR2FpBxMSYKQCocqDEkQu9gK0UsHU6lWa4FZrETsKY2UMSYwRgSWGQUQ5HqogTZCCbRIQBdkRJAp1%0AlUnbfFTEKq%2FECabYxSEoGboKDHs7SsjirnPPYkJSaCBCbURVIPK8XMnfmiXcKHVeEfiqxNeeQWlW%0AUGPtQEFkQm2aksuoiz1YmtlhCr%2BnRI7VyiR1XUgI4LQW97mp0iYEJpQNfqf1%2B752gThpXb1a8W%2BP%0APmDrZ1qbX2tVjthEW1MaE4XjPLirBF5c9ejOhVUXRyf2RdkJM0mdP9Cl52jAqBp6qYeTyGbj9amh%0AA820lpI5UtUz%2FFRzCe9i5Ac5JnfBhHSNvS8dyMW7kbLGoQeTCvYrG3go2PfhwUA%2Bft9Kt6ltHWKo%0AtTxS5M8me0QFuVCmM8uyaiZVcbLimF88x8scq%2FFIsPoFCmROWqOQ0BfmPFvhlzh1wsB9YfNb3LuS%0AIsgnnb%2F298S4azZ8SBW7QmkSOCmF%2BQbBCKJPiVLOQwWTYW79h9xxZc8G7K8ZIHAL83HirmFkg7fa%0A4N%2FFleC4dS5kKBIolMlTwZ6tMxuOVkDjT4941nVJSvt4ekUWtPAGov9LmHM%2FqolPB2TIgekGZkeQ%0At97I2jq4E9bd%2B0waiw%2BovLEltNbXg6y96nI934mhN27Om4IvTf3O8s4ncGGabZmYtdRZreRd%2FalT%0AFn2jLzReF7Uk260FfrxsyNmj1BnupUUXh3oZybpvGv25bxidmVmz%2BoP5dDYW8U1tWnaWwSJa9J7R%0AqLNmlw%2BcmuFgwyfCovFg4cPW8WqiLByWwkbmys%2FO8tC1rVkzHCZ7PR0LyR8kJCPnpgGDSXIYzafW%0AOHoViWc%2BNeqyG2F3uBwZdsAtpZss3fz0g3JXN5i7vAffrsniJ6D9BQ%3D%3D&RelayState=http%3A%2F%2Ftest.com%2Fvideo&SigAlg=rsa-sha1&Signature=Y1H5Hzy23ImzN59xvfm2K%2BoQ%2Bj76dVfqlm0qsj1DIxuVB3irxGndnYsr4jSBwlbmQum%2FHCH8Kre0%0AiCwfvEa0XzoV%2BJcjA%2BK1FuUxFQXXVkGCTfC%2FF4g6ZU9qnKsMo%2BRE19T1OSno%2BdOF%2B5oiI7F50mIu%0Ax2J6c1gNGXTcnLP8DuA%3D

Sample <RESPONSE> element NOT BASE64ENCODED:

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

<samlp:Response xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"

ID="IaqQrsXEBG" IssueInstant="2009-09-04T17:50:10.304Z" Version="2.0">

<samlp:Status>

<samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success" />

</samlp:Status>

<saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"

ID="gzTpHdtJoT" IssueInstant="2009-09-04T17:50:10.308Z" Version="2.0">

<saml:Issuer>

</saml:Issuer>

<saml:Subject>

<saml:NameID Format="DUID">MTY3MQ==</saml:NameID>

<saml:SubjectConfirmation Method="urn:oasis:names:tc:2.0:cm:holder-of-key">

<saml:SubjectConfirmationData xmlns:xsi=" xsi:type="saml:KeyInfoConfirmationDataType">

<ds:KeyInfo xmlns:ds="

<ds:KeyName>test_server_publickey</ds:KeyName>

</ds:KeyInfo>

</saml:SubjectConfirmationData>

</saml:SubjectConfirmation

</saml:Subject>

<saml:AttributeStatement>

<saml:Attribute Name="SPID">

<saml:AttributeValue xmlns:xs="

xmlns:xsi=" xsi:type="xs:string">

00000002

</saml:AttributeValue>

</saml:Attribute>

<saml:Attribute Name="eToken">

<saml:AttributeValue xmlns:xs="

xmlns:xsi=" xsi:type="xs:string"> bGQ42OynI9iMciMB19qdQTqboBl5cGw3R2Jn+ka3nhDhNwAgC/FfbpedR8W81f3UfBYEfseXMMA9sM4ubg9v5OB+2fIK16zX4rwvh10RY69wL3BPx3XColD+n9DfMIKWfIIBVM4TKNWUVR2o74U+bYiXmXFZnQBhceseUMlNk0r1X6JToyqbd4291yY1k9/+ZbYyCaTV8lPrxDuR1rjn1rQb76eiSryQWUTRmz2sdMO659cmocPYQIai/Y37wuk

</saml:AttributeValue>

</saml:Attribute>

</saml:AttributeStatement>

</saml:Assertion>

</samlp:Response>

At this point the Service Provider (SP) gets the Token from the Assertion’s eToken attribute parameter's value, and sends it to the Identity Provider using SOAP over a mutually authenticated HTTPS connection, the details of which are described in the DTV-IdP’s Authorization document: DTV-IdP-Authorization-ExternalIntegration-x.x.doc

HTTP POST Binding:The Assertion element of the SAML Response for HTTP Post binding is XML Encrypted. The encryption is done using symmetric key encryption. The key used for the encryption is RSA encrypted using client public certificate. Once the client receives the response, client can use their private key to decrypt the encrypted symmetric key. After this use the decrypted symmetric key to decipher the assertion element.

Sample Request POST Data

<input type="hidden" name="SAMLRequest" value="PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz48c2FtbHA6QXV0aG5SZXF1ZXN0IHhtbG5zOnNhbWxwPSJ1cm46b2FzaXM6bmFtZXM6dGM6U0FNTDoyLjA6cHJvdG9jb2wiIEFzc2VydGlvbkNvbnN1bWVyU2VydmljZVVSTD0iaHR0cDovLzEwLjIzLjE4Mi4yMzo4MDgwL2R0di1pZHAtY2xpZW50L2NvbnN1bWVBc3J0biIgSUQ9Il9tbWQyMjIiIElzc3VlSW5zdGFudD0iMjAwOS0wOS0wNFQxNzo1Mzo1OC4xNDVaIiBWZXJzaW9uPSIyLjAiPjxzYW1sOklzc3VlciB4bWxuczpzYW1sPSJ1cm46b2FzaXM6bmFtZXM6dGM6U0FNTDoyLjA6YXNzZXJ0aW9uIiBTUFByb3ZpZGVkSUQ9IjAwMDAwMDAyIj5odHRwOi8vMTAuMjMuMTgyLjIzOjgwODAvZHR2LWlkcC1jbGllbnQvPC9zYW1sOklzc3Vlcj48ZHM6U2lnbmF0dXJlIHhtbG5zOmRzPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwLzA5L3htbGRzaWcjIj4KPGRzOlNpZ25lZEluZm8+CjxkczpDYW5vbmljYWxpemF0aW9uTWV0aG9kIEFsZ29yaWcjIj4KPGRzOlNpZ25lZEluZm8+aXRobT0iaHR0cDovL3d3dy53My5vcmcvMjAwMS8xMC94bWwtZXhjLWMxNG4jIi8+CjxkczpTaWdubT0iaHR0cDovL3d3dy53My5vcmcvMjAwMS8xMC94bWwtZXhjLWMxNG4jIi8+YXR1cmVNZXRob2QgQWxnb3JpdGhtPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwLzA5L3htbGRzaWcjcnNhLXNoYTEiLz4KPGRzOlJlZmVyZW5jZSBVUkk9IiNfbW1kMjIyIj4KPGRzOlRyYW5zZm9ybXM+CjxkczpUcmFuc2Zvcm0gQWxnb3JpdGhtPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwLzA5L3htbGRzaWcjZW52ZWxvcGVkLXNpZ25hdHVyZSIvPgo8ZHM6VHJhbnNmb3JtIEFsZ29yaXRobT0iaHR0cDovL3d3dy53My5vcmcvMjAwMS8xMC94bWwtZXhjLWMxNG4jIj48ZWM6SW5jbHVzaXZlTmFtZXNwYWNlcyB4bWxuczplYz0iaHR0cDovL3d3dy53My5vcmcvMjAwMS8xMC94bWwtZXhjLWMxNG4jIiBQcmVmaXhMaXN0PSJkcyBzYW1sIHNhbWxwIi8+PC9kczpUcmFuc2Zvcm0+CjwvZHM6VHJhbnNmb3Jtcz4KaXN0PSJkcyBzYW1sIHNhbWxwIi8+PC9kczpUcmFuc2Zvcm0+PGRzOkRpZ2VzdE1ldGhvZCBBbGdvcml0aG09Imh0dHA6Ly93d3cudzMub3JnLzIwMDAvMDkveG1sZHNpZyNzaGExIi8+CjxkczpEaWdlc3RWYWx1ZT5WNzR5OHpQMGJaczE4djFRc2pDcExxRUlEMjA9ZyNzaGExIi8+PC9kczpEaWdlc3RWYWx1ZT4KPC9kczpSZWZlcmVuY2U+CjwvZHM6U2lnbmVkSW5mbz4KPGRzOlNpczpEaWdlc3RWYWx1ZT4KPC9kczpSZWZlcmVuY2U+Z25hdHVyZVZhbHVlPgpTS2dDekd1N3F0TzN2aVhJQmN4RVlGV3hsWmNodEc4bXJyTStBTkFYUHhRTDlWSFhlNkNaTERiNWJCcExSekZwU3A3Tyt4UGwzc3IwCmFQVVpaWFIzdGF0SnNiV1hhOXd3aU9Cc1Q3d3BYMThRMlBUbXJMcFFuTU4wYWhKUEh4WUpVZU9MTlRHWithQlNvL2hMT3VNSm8rN1oKb0JZa0lBVDJocFZ4dzBzUURlQT0KPC9kczpTaWduYXR1cmVWYWx1ZT4KPC9kczpTaWduYXR1cmU+PHNhVDJocFZ4dzBzUURlQT0KPC9kczpTaWduYXR1cmVWYWx1ZT4KPC9kczpTaWduYXR1cmU+bWw6U3ViamVjdCB4bWxuczpzYW1sPSJ1cm46b2FzaXM6bmFtZXM6dGM6U0FNTDoyLjA6YXNzZXJ0aW9uIj48c2FtbDpTdWJqZWN0Q29uZmlybWF0aW9uIE1ldGhvZD0idXJuOm9hc2lzOm5hbWVzOnRjOjIuMDpjbTpob2xkZXItb2Yta2V5Ij48c2FtbDpTdWJqZWN0Q29uZmlybWF0aW9uRGF0YSB4bWxuczp4c2k9Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvWE1MU2NoZW1hLWluc3RhbmNlIiB4c2k6dHlwZT0ic2FtbDpLZXlJbmZvQ29uZmlybWF0aW9uRGF0YVR5cGUiPjxkczpLZXlJbmZvIHhtbG5zOmRzPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwLzA5L3htbGRzaWcjIj48ZHM6S2V5TmFtZT50ZXN0X2NsaWVudF9wdWJsaWNrZXk8L2RzOktleU5hbWU+PC9kczpLZXlJbmZvPjwvc2FtbDpTdWJqZWN0Q29udF9wdWJsaWNrZXk8L2RzOktleU5hbWU+ZmlybWF0aW9uRGF0YT48L3NhbWw6U3ViamVjdENvbmZpcm1hdGlvbj48L3NhbWw6U3ViamVjdD48L3NhbWxwOkF1dGhuUmVxdWVzdD4=">

<input type="hidden" name="RelayState" value="

Before Base64 Encoding the SAML Request

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

<samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"

AssertionConsumerServiceURL= ID="_mmd222" IssueInstant="2009-09-04T17:52:11.530Z" Version="2.0">

<saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"

SPProvidedID="00000002">

</saml:Issuer>

<ds:Signature xmlns:ds="

<ds:SignedInfo>

<ds:CanonicalizationMethod Algorithm=" />

<ds:SignatureMethod Algorithm=" />

<ds:Reference URI="#_mmd222">

<ds:Transforms>

<ds:Transform Algorithm=" />

<ds:Transform Algorithm="

<ec:InclusiveNamespaces xmlns:ec="

PrefixList="ds saml samlp" />

</ds:Transform>

</ds:Transforms>

<ds:DigestMethod Algorithm=" />

<ds:DigestValue>dRj9WltSsAgONHNsZ52osLzKYnQ=

</ds:DigestValue>

</ds:Reference>

</ds:SignedInfo>

<ds:SignatureValue>U22Mo9SDC/PEgCHLGLul/jnED9MhSnJhfL8ue1M6WswTdbfiMAmaWAGKnc8LpsuZJ+LZ0O8yaJB8Ht48+TLzNSeibDwy03e22ymjqvcJRtYR3dAO//BBKWgv/Wiu/koOBWmP9Le/XQ4FeiAqFe2XZotLaBDvIcqH0GbclBypkjY=

</ds:SignatureValue>

</ds:Signature>

<saml:Subject xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">

<saml:SubjectConfirmation Method="urn:oasis:names:tc:2.0:cm:holder-of-key">

<saml:SubjectConfirmationData

xmlns:xsi=" xsi:type="saml:KeyInfoConfirmationDataType">

<ds:KeyInfo xmlns:ds="

<ds:KeyName>test_client_publickey</ds:KeyName>

</ds:KeyInfo>

</saml:SubjectConfirmationData>

</saml:SubjectConfirmation>

</saml:Subject>

</samlp:AuthnRequest>

Sample Response POST Data

<input type="hidden" name="SAMLResponse"

value="PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz48c2FtbHA6UmVzcG9uc2UgeG1sbnM6c2FtbHA9InVybjpvYXNpczpuYW1lczp0YzpTQU1MOjIuMDpwcm90b2NvbCIgSUQ9Im5DeEJtZ3lJelMiIElzc3VlSW5zdGFudD0iMjAwOS0wOS0wNFQxNzo1NTo0Ny44NTVaIiBWZXJzaW9uPSIyLjAiPjxzYW1scDpTdGF0dXM+PHNhbWxwOlN0YXR1c0NvZGUgVmFsdWU9InVybjpvYXNpczpuLjAiPjxzYW1scDpTdGF0dXM+YW1lczp0YzpTQU1MOjIuMDpzdGF0dXM6U3VjY2VzcyIvPjwvc2FtbHA6U3RhdHVzPjxzYW1sOkFzc2VydGlvbiB4bWxuczpzYW1sPSJ1cm46b2FzaXM6bmFtZXM6dGM6U0FNTDoyLjA6YXNzZXJ0aW9uIiBJRD0iYmtCaWFwQ21TQSIgSXNzdWVJbnN0YW50PSIyMDA5LTA5LTA0VDE3OjU1OjQ3Ljg1NVoiIFZlcnNpb249IjIuMCI+PHNhbWw6SXNzdWVyPmh0dHBzOi8vZGV2LWlkcC5kdHZjZS5jb208L3NhcnNpb249IjIuMCI+bWw6SXNzdWVyPjxkczpTaWduYXR1cmUgeG1sbnM6ZHM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDAvMDkveG1sZHNpZyMiPgo8ZHM6U2lnbmVkSW5mbyB4bWxuczpkcz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC8wOS94bWxkc2lnIyI+CjxkczpDYW5vbmljYWxpemF0aW9uTWV0aG9kIEFsZ29yaXRobT0iMC8wOS94bWxkc2lnIyI+aHR0cDovL3d3dy53My5vcmcvMjAwMS8xMC94bWwtZXhjLWMxNG4jIiB4bWxuczpkcz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC8wOS94bWxkc2lnIyIvPgo8ZHM6U2lnbmF0dXJlTWV0aG9kIEFsZ29yaXRobT0iaHR0cDovL3d3dy53My5vcmcvMjAwMC8wOS94bWxkc2lnI3JzYS1zaGExIiB4bWxuczpkcz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC8wOS94bWxkc2lnIyIvPgo8ZHM6UmVmZXJlbmNlIFVSST0iI2JrQmlhcENtU0EiIHhtbG5zOmRzPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwLzA5L3htbGRzaWcjIj4KPGRzOlRyYW5zZm9ybXMgeG1sbnM6ZHM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDAvMDkveG1sZHNpZyMiPgo8ZHM6VHJhbnNmb3JtIEFsZ29yaXRobT0iaHR0cDovL3d3dy53My5vcmcvMjAwMC8wOS94bWxkc2lnI2VudmVsb3BlZC1zaWduYXR1cmUiIHhtbG5zOmRzPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwLzA5L3htbGRzaWcjIi8+CjxkczpUcmFuc2Zvcm0gQWxnb3JpdGhtPSJodHRwOi8vZy8yMDAwLzA5L3htbGRzaWcjIi8+d3d3LnczLm9yZy8yMDAxLzEwL3htbC1leGMtYzE0biMiIHhtbG5zOmRzPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwLzA5L3htbGRzaWcjIj48ZWM6SW5jbHVzaXZlTmFtZXNwYWNlcyB4bWxuczplYz0iaHR0cDovL3d3dy53My5vcmcvMjAwMS8xMC94bWwtZXhjLWMxNG4jIiBQcmVmaXhMaXN0PSJkcyBzYW1sIHhzIi8+PC9kczpUcmFuc2Zvcm0+CjwvZHM6VHJhbnNmb3Jtcz4KPGRzOkRpZ2VzdE1ldGhvIHhzIi8+PC9kczpUcmFuc2Zvcm0+ZCBBbGdvcml0aG09Imh0dHA6Ly93d3cudzMub3JnLzIwMDAvMDkveG1sZHNpZyNzaGExIiB4bWxuczpkcz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC8wOS94bWxkc2lnIyIvPgo8ZHM6RGlnZXN0VmFsdWUgeG1sbnM6ZHM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDAvMDkveG1sZHNpZyMiPlUzTWtrelhlODNtT2JUVzgzRi9CdkxvL3kvST08L2RzOkRpZ2VzdFZhbHVlPgo8L2RzOlJlZmVyZW5jZT4KPC9kczpTaWduZWRJbmZvPgo8ZHM6U2lnbmF0dXJlVmFsdWUgeG1sbnM6ZHM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDAvMDkveG1sZHNpZyMiPgpMMitXVUkvVnJvdW1NZ05uSFRJZFlCTUp6QlJIUEdIOGNOd0ZpZ3V6cjFEclZSUFoyUDFybU5MM2p5S0wxbC9XdktoMkRpNEU5T2FXCllBNGxDZVJPVUk5YnEwclIxdTMxVURuZGMyQndXeEtGdWUvdkx3WkQwTTl5Yzk5azZJa05GbWY0eTMrcTZjekZzVk5GdFByUDZENkIKb2JEVTAyZmRnUWcrOXZ3eGYzRT0KPC9kczpTaWduYXR1cmVWYWx1ZT4KPC9kczpTaWduYXR1cmU+PHNhbWw6U3ViamVjdD48c2FtbDpOYW1lSUQgRm9ybWF0PSJEVUlEIj5NVFkzTVE9PTwvcmU+c2FtbDpOYW1lSUQ+PHNhbWw6U3ViamVjdENvbmZpcm1hdGlvbiBNZXRob2Q9InVybjpvYXNpczpubDpOYW1lSUQ+YW1lczp0YzoyLjA6Y206aG9sZGVyLW9mLWtleSI+PHNhbWw6S2V5SW5mb0NvbmZpcm1hdGlvbkRhczp0YzoyLjA6Y206aG9sZGVyLW9mLWtleSI+dGFUeXBlPjxkczpLZXlJbmZvIHhtbG5zOmRzPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwLzA5L3htbGRzaWcjIj48ZHM6S2V5TmFtZT50ZXN0X3NlcnZlcl9wdWJsaWNfa2V5PC9kczpLZXlOYW1lPjwvZHM6S2V5SW5mbz48L3NhbWw6S2V5SW5mb0NvbmZpcm1hdGlvbkRhdGFUeXBlPjwvc2FtbDpTdWJqZWN0Q29uZmlybWF0aW9uPjwvc2FtbDpTdWJqZWN0PjxzYW1sOkF0dHJpYnV0ZVN0YXRlbWVudD48c2FtbDpBdHRyaWJ1dGUgTmFtZT0iU1BJRCI+PHNhbWw6QXR0cmlidXRlVmFsdWUgeG1sbnM6eHM9bDpBdHRyaWJ1dGUgTmFtZT0iU1BJRCI+Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvWE1MU2NoZW1hIiB4bWxuczp4c2k9Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvWE1MU2NoZW1hLWluc3RhbmNlIiB4c2k6dHlwZT0ieHM6c3RyaW5nIj4wMDAwMDAwMjwvc2FtbDpBdHRyaWJ1dGVWYWx1ZT48L3NhbWw6QXR0cmlidXRlPjxzYW1sOkF0dHJpYnV0ZSBOYW1lPSJlVG9rZW4iPjxzYW1sOkF0dHJpYnV0ZVZhbHVlIHhtbG5zOnhzPSJodHRwOi8vd3d3LnczLm9yZy8yMDAxL1hNTFNjaGVtYSIgeG1sbnM6eHNpPSJodHRwOi8vd3d3LnczLm9yZy8yMDAxL1hNTFNjaGVtYS1pbnN0YW5jZSIgeHNpOnR5cGU9InhzOnN0cmluZyI+YkdRNDJPeW5JOWlNY2lNTFNjaGVtYS1pbnN0YW5jZSIgeHNpOnR5cGU9InhzOnN0cmluZyI+QjE5cWRRVHFib0JsNWNHdzNSMkpuK2thM25oRGhOd0FnQy9GZmJwZWRSOFc4MWYzVWZCWUVmc2VYTU1BOXNNNHViZ2c5djVPQisyZklLMTZ6WDRyd3ZoMTBSWTY5d0wzQlB4M1hDb2xEK245RGZNSUtXZklJQlZNNFRLTldVVlIybzc0VStiWWlYbVhGWm5RQmhjZXNlVU1sTmswcjFYNkpUb3lxYmQ0MjkxeVkxazkvK1piWXlDYVRWOGxQcnhEdVIxcmpuMXJRYjc2ZWlTcnlRV1VUUm16MnNkTU82NTljbW9jUFlRSWFpL1kzN3d1azwvc2FtbDpBdHRyaWJ1dGVWYWx1ZT48L3NhbWw6QXR0cmlidXRlPjwvc2FtbDpBdHRyaWJ1dGVTdGF0ZW1lbnQ+PC9zYW1sOkFzc2VydGlvbj48L3NhbWxwOlJlc3BvbnNlPg==dHRyaWJ1dGVTdGF0ZW1lbnQ+">

<input type="hidden" name="RelayState"

value="

Before Base 64 Encoding:

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

<samlp:Response xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"

ID="nCxBmgyIzS" IssueInstant="2009-09-04T17:55:47.855Z" Version="2.0">

<samlp:Status>

<samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success" />

</samlp:Status>

<saml:EncryptedAssertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">

<xenc:EncryptedData xmlns:xenc=" Id="_732385b2df8c5246e3487b4e15d25239" Type="

<xenc:EncryptionMethod Algorithm=" xmlns:xenc="

<ds:KeyInfo xmlns:ds="

<ds:RetrievalMethod Type=" URI="#_5a75f4ac2a0684834e1af83afb788504"/>

</ds:KeyInfo>

<xenc:CipherData xmlns:xenc="

<xenc:CipherValue xmlns:xenc="

n+KIiUqunceV8SYI8jIkgi0RKed2//A/nmZ0Rk7RCIJgBgDeVXrfRvVFsZ91XIzqkrTOESgln+w8Dh2n2wDDOvNyO8ZPxAay/k5YEYWfmmj8I7MrcdBt2UrBtH2VzBXHccTUXot8xpWao4tlojndom0xwXwrQldxuXakK0NHC8ZL2M41qFG44AwiaojT3c7QNrDR1vqdKQ4vW56tokQzvtbuLAAzp4egbbIKjm6kY1ur65Pb882yPdVBCpy33TVaD3okvey1lD8zutCSV0qQdFnRRJFWlUPP5FAW4KunVLrTFpWAOA/PJrwQ2Ku0R5ZcPe+Va7dAetAdtXzQTA+7llStiA3of0sC6gfyMma4bHgqfAetAYXlecIIVOcLYBOLoMqHMUoCZqqdkYWvta09+MYlKftVxztnv/F1MlgafrsQE5ButjHf6fMBbopJS2MNDI4lCdOLoMqHMUoCZqqdkYWvta09+QoMjpVjCLlmC07gVDddqZKo2f1SpC1uZIQfrFmoyaSFy7JeHNVlLh9zQlLj7AyKqaVqN9zYYcgBezsgziPzS16fQCUr4sU6v+tNL2vfLqTgAQc+sVngjaw8gHxHz4jLHXFCwk71OdFr0J/O1/jOoIvGiiPzS16fQCUr4sU6v+tNL2vfLqTgAQc+ULU0WW3Tv+hiicvDAShbMIN/lW3/l923psIdlRh7ChdgUT6rFE41bFH509cY2OFoePKaNKUJmZNkWW3Tv+ZrenxqIBWgPvLiEIw6g52ueihD5ngH+nNXPcNT4MC7zRrkDJNowG1fqkMFhrCRk48QSCFDdqpTBVxqIBWgPvLiEIw6g52ueihD5ngH+3HHRILry+/q+ygrhj2I96zwRi1MJgo/YIVjvWlXvTzt33jGVJfpxY/oRGdTvR/n6nH2wt8NYkZpIILry+sjC35leci/vmoH488q03uF+NuBkMCbZU4gduR6Cvm7RVmCGw+5wpid5DtEn3jll3YQ5cnidnzpnNmf+GgVm2wc/dv1d4ZHc7VMXWTguQXs7PQazqqf8G3IQOBu2tEIRPDraSDv0ihSzi/TenMZh3WoPUHqs/aLqA+hZPmXd5/nkUahqT/CU+8tUEflqjpHp1ruXOFwgeTgLY5ZURStueQEEZoKGrufNPQae/aLqA+FE6PftkizBy1j/jlyjQGSrlXkmzB5k0EdzONKbqqXe0yDfQ9UJZpVOacXtrHfZxzJdSjjA/HfiokFWFrLmeMx5tK6DtfmoGAdBCkn31DUV5zk0D7qUx9QZSzZTjTZB6fh9nTvfvJ/S4/vT2FLnf1iUZvq3nqqAgavo9X6SNbLdLDB3qXzSkV1pjKqGez5bVna9RKRbKVv+M6cJorpgj0Gqcx2D3DuW3X5DgBqAgavo9X6SNbLdLDB3qXzSkV1pjKqGez5bVna9RKRbKVv+XDFqCGm4FNbxYKC7k7RNXQQPsR0bXEbcvuBmJ2/ZvUvEiXV9sbYRvx1JUhjS4M9Gb1Zb3x+7x5TSeS5o/IPMzktgnPOtNIzR9iz5P/B35vs9WafJy+q9F4KitThvLFKu7eIw9JvupHUw+CIgMa0UqQ9IT6u6Co0nRDLgScLb6bj54xtX4XKGf/Fv2bWOxySeWDBL5zrj3g4XfoehPmnuwyVt9ikYK4PNIypvM0TnaKsvnExRIHFMDW5dU/IzajzHaMR9+HqvjnUquuu3NgUFAsIcmtzcCttqK7sT78fP/afsEpRdjE/0NzPySsWhgOwusuH4/P6eFWFQ4pk0fhobgTCO7Ix7EaeuLJyRSO3Jdl/wm2A0Kv8/CkpsYwta3LC6xVGqEAR+O40WW2hPnKpN1XRfN+nCDDlDHbM/u1XoW6KI5UjRI8W+tVHd5H3uAS64PWuMpOUtxVGqEAR+O40WW2hPnKpN1XRfN+7aSDu6kmZ+Rg7ToAErTFA+2spNw8rK0gFgTUvFlJ5yp+iPau+vMAhGcUwR6wBPhcJsih4gLsDI75u6kmZ+Rg7ToAErTFA+2spNw8rK0gFgTUvFlJ5yp+iPau+M7TdG50ytG8tN8VTRkf4BR3BGx7QZEO8n73bDiPcLXBMiodWGhrHMz/rXaSZYrwRN72ixONi9W34Ew1lfgUVPwW243EyLw5UQ4jmDO1bRynLaG1BCLNkumTFp18zVIWcQ8LhFGEQpa+2nJHWYXefngLnfgUVPwW243EyLw5UQ4jmDO1bRynLaG1BCLNkumTFp18zVIWcQ8LhFGEQpa+fna3YMW9bS8skdUDNZZrQ9LJJPJb66n7igiqnWvFl3K3uvoXdp4z/GaTqEJ0dx2dsjdUpVV7zHFkveIX3lqfo4Sh9T3DfsB/Qtp7jTbmU+H4fPXEN621PZwss2O3kUeI7YRLVqDjDka40yifUHw3drmgwFro

fTcbWwg88FK+S4hrGn/U2IogkNtgfA==

</xenc:CipherValue>

</xenc:CipherData>

</xenc:EncryptedData>

<xenc:EncryptedKey xmlns:xenc= Id="_5a75f4ac2a0684834e1af83afb788504">

<xenc:EncryptionMethod Algorithm=" xmlns:xenc="

<xenc:CipherData xmlns:xenc="

<xenc:CipherValue xmlns:xenc="

ZJzo7w1BOnQ5cTYTLUwfZcKrv/fQyeaoEyRYB8UhfvskiuttZ9qMJPggpB6lTwh5QHeUrtLPBhlWoMjwvzqJ0zOmO3rH7V4=

</xenc:CipherValue>

</xenc:CipherData>

<xenc:ReferenceList>

<xenc:DataReference URI="#_732385b2df8c5246e3487b4e15d25239"/>

</xenc:ReferenceList>

</xenc:EncryptedKey>

</saml:EncryptedAssertion>

</samlp:Response>

Unencrypted Assertion:

<saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"

ID="bkBiapCmSA" IssueInstant="2009-09-04T17:55:47.855Z" Version="2.0">

<saml:Issuer>

</saml:Issuer>

<ds:Signature xmlns:ds="

<ds:SignedInfo xmlns:ds="

<ds:CanonicalizationMethod Algorithm="

xmlns:ds=" />

<ds:SignatureMethod Algorithm="

xmlns:ds=" />

<ds:Reference URI="#bkBiapCmSA" xmlns:ds="

<ds:Transforms xmlns:ds="

<ds:Transform Algorithm="

xmlns:ds=" />

<ds:Transform Algorithm="

xmlns:ds="

<ec:InclusiveNamespaces xmlns:ec="

PrefixList="ds saml xs" />

</ds:Transforms>

<ds:DigestMethod Algorithm="

xmlns:ds=" />

<ds:DigestValue xmlns:ds=" U3MkkzXe83mObTW83F/BvLo/y/I=

</ds:DigestValue>

</ds:Reference>

</ds:SignedInfo>

<ds:SignatureValue xmlns:ds="

L2+WUI/VroumMgNnHTIdYBMJzBRHPGH8cNwFiguzr1DrVRPZ2P1rmNL3jyKL1l/WvKh2Di4E9OaWYA4lCeROUI9bq0rR1u31UDndc2BwWxKFue/vLwZD0M9yc99k6IkNFmf4y3+q6czFsVNFtPrP6D6BobDU02fdgQg+9vwxf3E=

</ds:SignatureValue>

</ds:Signature>

<saml:Subject>

<saml:NameID Format="DUID">MTY3MQ==</saml:NameID>

<saml:SubjectConfirmation Method="urn:oasis:names:tc:2.0:cm:holder-of-key">

<saml:SubjectConfirmationData xmlns:xsi=" xsi:type="saml:KeyInfoConfirmationDataType">

<ds:KeyInfo xmlns:ds="

<ds:KeyName>test_server_publickey</ds:KeyName>

</ds:KeyInfo>

</saml:SubjectConfirmationData>

</saml:SubjectConfirmation

</saml:Subject>

<saml:AttributeStatement>

<saml:Attribute Name="SPID">

<saml:AttributeValue xmlns:xs="

xmlns:xsi=" xsi:type="xs:string">

00000002

</saml:AttributeValue>

</saml:Attribute>

<saml:Attribute Name="eToken">

<saml:AttributeValue xmlns:xs="

xmlns:xsi=" xsi:type="xs:string"> bGQ42OynI9iMciMB19qdQTqboBl5cGw3R2Jn+ka3nhDhNwAgC/FfbpedR8W81f3UfBYEfseXMMA9sM4ubgg9v5OB+2fIK16zX4rwvh10RY69wL3BPx3XColD+n9DfMIKWfIIBVM4TKNWUVR2o74U+bYiXmXFZnQBhceseUMlNk0r1X6JToyqbd4291yY1k9/+ZbYyCaTV8lPrxDuR1rjn1rQb76eiSryQWUTRmz2sdMO659cmocPYQIai/Y37wuk

</saml:AttributeValue>

</saml:Attribute>

</saml:AttributeStatement>

</saml:Assertion>

4SP features required for Authentication

This documentdoes not address the following features they need to be addressed by the SP:

  • Session management for the user in context of the Web Application (Service Provider).
  • The details of maintaining the cookies and their expiration times.

5Common Domain Cookie Support

DTV-IdP will include support for writing to Common Domain Cookie as specified in Section 4.3 of “saml-profiles-2.0-os.pdf”. Service Providers would need to read the common domain cookie to determine if the browser is already hasa profile with DTV-IdP. The naming convention and the contents within a Common Domain Cookie strictly adhere to Sections 4.3.1, 4.3.2 and 4.3.3of “saml-profiles-2.0-os.pdf”. The detailed specification/documentation about DTV_IDP Discovery Service and Writer Service will be released later.

DTVIdPRevokeToken: A call to this method revokes theToken. Once aToken is revoked it is no longer valid.(TBD)

DTVIdPTokenInfo: A call to this method verifies whether a specified Token is valid and returns data associated with the Token. (TBD)

7Error Codes

If DTV-IdP’s request fails, you may receive any of a variety of HTTP error status codes in response. In particular, if the problem is with the account itself (rather than the authentication token as such), you'll receive one of the following 403 errors:

  • 403 Account disabled
  • 403 Account deleted

If the problem is with the authentication Assertion, following errors will be in response:

  • 401 Assertion invalid
  • 401 Signature Verification Failed
  • 401 Authentication Request does not confirm to the schema.
  • 401 Assertion disabled
  • 401 Assertion expired
  • 401 Assertion revoked

Error responses may also include a DTVIdP-Authentication header, such as the following:

DTVIdP-Authentication: DTVAuthn realm="

That header provides information about how and where to authenticate correctly.

8References

  1. Security Assertion Markup Language(SAML) V2.0 Overview:
  1. Schemas for SAML queries and responses: saml-schema-protocol-2.0.xsd

DirecTV IdP Authentication Specification / Page 1

DIRECTV Confidential

Do not copy without prior DIRECTV authorization