OpenID Signed Assertions 1.0 - Draft 1

Dick Hardt dick at sxip.com
Tue Dec 5 00:37:17 UTC 2006


Hi Paul

Would be keen to converge. Are you at IIW? I see SAML and OpenID  
converging, both for assertions as well as for future OpenID  
messages. Is this something you are interested in?

-- Dick

On 4-Dec-06, at 8:48 AM, Paul Madsen wrote:

> Hi Dick, Eve Maler and I were thinking along the same lines and  
> drafted the enclosed SAML Attribute profile for the OpenID  
> SimpleReg extension.
>
> It has less grand ambitions than yours (e.g. no signing) but  
> otherwise seems nicely aligned
>
> Regards
>
> Paul
>
> p.s. and our profile bears a debt to John's initial DIX spec as well
>
> Dick Hardt wrote:
>> Hello List
>>
>> Attached is a specification for using SAML to bind properties to  
>> an OpenID Identifier. The mechanism for refreshing the Assertion  
>> still needs to be worked out. Look forward to discussing this and  
>> the Attribute Exchange specifications at IIW with those of you there.
>>
>> -- Dick
>>
>>
>>
>> --------------------------------------------------------------------- 
>> ---
>>
>> TOC <#toc>
>>
>> Draft 	D. Hardt
>> 	Sxip Identity
>> 	November 2006
>>
>>
>>
>>   OpenID Signed Assertions 1.0 - Draft 01
>>
>>
>>       Abstract
>>
>> This document describes a SAML assertion schema extension for  
>> encoding third-party attested attribute value claims as OpenID  
>> attributes for use with the OpenID Attribute eXchange service.
>>
>>
>> --------------------------------------------------------------------- 
>> ---
>>
>>
>>       Table of Contents
>>
>> 1. <#anchor1> Introduction
>> 2. <#anchor2> Terminology
>> 2.1. <#anchor3> Definitions and Conventions
>> 3. <#anchor4> SAML Introduction
>> 3.1. <#anchor5> SAML Assertions
>> 4. <#anchor6> Employing SAML in OpenID
>> 4.1. <#anchor7> Assertion Attributes
>> 5. <#saml-attribute> OpenID SAML Attribute Profile
>> 5.1. <#anchor8> Required Information
>> 5.2. <#anchor9> SAML Attribute Naming
>> 5.3. <#anchor10> Profile-Specific XML Attributes
>> 5.4. <#anchor11> SAML Attribute Values
>> 5.5. <#anchor12> Example
>> 6. <#saml-assertion> Assertion Schema Extension
>> 6.1. <#anchor13> Element openid:Assertion
>> 6.1.1. <#anchor14> Element saml:Assertion
>> 7. <#assertion-schema> OpenID Assertion Schema
>> 8. <#refresh> Refreshing an Assertion
>> 9. <#example-assertion> Example Signed SAML Assertion
>> 10. <#anchor19> Security Considerations
>> 11. <#anchor20> Acknowledgements
>> 12. <#rfc.references1> References
>> 12.1. <#rfc.references1> Normative References
>> 12.2. <#rfc.references2> Informative References
>> § <#rfc.authors> Author's Address
>>
>>
>>
>> --------------------------------------------------------------------- 
>> ---
>> TOC <#toc>
>>
>>
>>       1. Introduction
>>
>> This document specifies an assertion schema extension of the  
>> Security Assertion Markup Language (SAML) V2.0 called 'OpenID  
>> Signed Assertions', for use with the OpenID  
>> [OpenID.authentication‑2.0] (Recordon, D., Hoyt, J., Fitzpatrick,  
>> B., and D. Hardt, “OpenID Authentication 2.0 - Draft 10,”  
>> August 2006.) <#OpenID.authentication-2.0> Attribute eXchange  
>> service [OpenID.attribute‑exchange‑1.0] (Hardt, D., “OpenID  
>> Attribute Exchange 1.0 - Draft 03,” November 2006.)  
>> <#OpenID.attribute-exchange-1.0>.
>>
>> Security Assertion Markup Language (SAML) v2.0, "SAMLv2", is an  
>> XML-based framework for creating and exchanging security  
>> information. The SAMLv2 specification set is normatively defined  
>> by [OASIS.saml‑conformance‑2.0‑os] (Mishra, P., Philpott, R.,  
>> and E. Maler, “Conformance Requirements for the Security  
>> Assertion Markup Language (SAML) V2.0,” March 2005.) <#OASIS.saml- 
>> conformance-2.0-os>.
>>
>>
>> --------------------------------------------------------------------- 
>> ---
>> TOC <#toc>
>>
>>
>>       2. Terminology
>>
>> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL  
>> NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"  
>> in this document are to be interpreted as described in [RFC2119]  
>> (Bradner, S., “Key words for use in RFCs to Indicate Requirement  
>> Levels,” March 1997.) <#RFC2119>.
>>
>>
>> --------------------------------------------------------------------- 
>> ---
>> TOC <#toc>
>>
>>
>>       2.1. Definitions and Conventions
>>
>> [NOTE: Update terminology based on final OpenID 2.0 draft.]
>>
>> In this specification, the term, or term component, "SAML" refers  
>> to SAML V2.0 in all cases. For example, the term "SAML assertion"  
>> implicitly means "SAMLv2 assertion".
>>
>> For overall SAML terminology, see  
>> [OASIS.saml‑glossary‑2.0‑os] (Hodges, J., Philpott, R., and  
>> E. Maler, “Glossary for the Security Assertion Markup Language  
>> (SAML) V2.0,” March 2005.) <#OASIS.saml-glossary-2.0-os>.
>>
>> Conventional XML namespace prefixes are used throughout this  
>> specification to stand for their respective namespaces as follows,  
>> whether or not a namespace declaration is present in the example:
>>
>>     Prefix: openid
>>         XML Namespace: http://openid.net/xmlns/2.0.     Prefix: ds
>>         XML Namespace: http://www.w3.org/2000/09/xmldsig#. This
>>         namespace is defined in the XML Signature Syntax and
>>         Processing specification  
>> [W3C.REC‑xmldsig‑core‑20020212]
>>         (Solo, D., Eastlake, D., and J. Reagle, “XML-Signature  
>> Syntax
>>         and Processing,” February 2002.)
>>         <#W3C.REC-xmldsig-core-20020212> and its governing  
>> schema.     Prefix: saml
>>         XML Namespace: urn:oasis:names:tc:SAML:2.0:assertion. This is
>>         the SAML V2.0 assertion namespace  
>> [OASIS.saml‑core‑2.0‑os]
>>         (Cantor, S., Kemp, J., Philpott, R., and E. Maler,  
>> “Assertions
>>         and Protocol for the OASIS Security Assertion Markup Language
>>         (SAML) V2.0,” March 2005.) <#OASIS.saml-core-2.0-os>.
>>
>> --------------------------------------------------------------------- 
>> ---
>> TOC <#toc>
>>
>>
>>       3. SAML Introduction
>>
>> SAML [OASIS.saml‑core‑2.0‑os] (Cantor, S., Kemp, J.,  
>> Philpott, R., and E. Maler, “Assertions and Protocol for the  
>> OASIS Security Assertion Markup Language (SAML) V2.0,” March  
>> 2005.) <#OASIS.saml-core-2.0-os> defines an XML-based framework  
>> for exchanging "security assertions" between entities.
>>
>> SAML can be employed to make and encode statements such as "Beth  
>> has these profile attributes and her domain's certificate is  
>> available over there, and I'm making this statement, and here's  
>> who I am."
>>
>> A SAML assertion profile is the specification of the assertion  
>> schema extension in the context of a particular SAML profile. It  
>> is possibly further qualified by a particular implementation and/ 
>> or deployment context. Condensed examples of SAML assertion  
>> profiles are:
>>
>>     * The SAML assertion must contain at least one authentication
>>       statement and no other statements. The relying party must be
>>       represented in the <AudienceRestriction> element. The
>>       SubjectConfirmation Method must be Foo. etc.
>>     * The SAML assertion must contain at least one attribute  
>> statement
>>       and may contain more than one. The values for the subject's
>>       profile attributes named "Foo" and "Bar" must be present. An
>>       authentication statement may be present. etc.
>>
>>
>> --------------------------------------------------------------------- 
>> ---
>> TOC <#toc>
>>
>>
>>       3.1. SAML Assertions
>>
>> A SAML assertion is a package of information including issuer and  
>> subject, conditions and advice, and/or attribute statements, and/ 
>> or authentication statements and/or other statements. Statements  
>> may or may not be present. The SAML assertion "container" itself  
>> contains the following information:
>>
>>     Issuing information:
>>         Who issued the assertion, when was it issued and the  
>> assertion
>>         identifier.     Subject information:
>>         The name of the subject, the security domain and optional
>>         subject information, like public key.     Conditions under  
>> which the assertion is valid:
>>         Special kind of conditions like assertion validity period,
>>         audience restriction and target restriction.      
>> Additional advice:
>>         Explaining how the assertion was made, for example.
>> In terms of SAML assertions containing SAML attribute statements,  
>> here is an explanatory example:
>>
>>     With a SAML assertion containing a SAML attribute statement, an
>>     issuing authority is asserting that the subject is associated  
>> with
>>     certain attributes with certain subject profile attribute values.
>>     For example, user http://www.home.com/beth is associated with the
>>     attribute http://openid.net/schema/contact/internet/email, which
>>     has the value beth at home.com.
>>
>>
>> --------------------------------------------------------------------- 
>> ---
>> TOC <#toc>
>>
>>
>>       4. Employing SAML in OpenID
>>
>> Employing SAML in OpenID necessitates devising a new SAML  
>> Assertion Profile and a new SAML Attribute Profile because those  
>> already specified in the SAMLv2 specification set are specific to  
>> other use contexts and use cases. This does not present any  
>> untoward difficulties due to SAML's inherent and explicit  
>> extensibility.
>>
>>
>> --------------------------------------------------------------------- 
>> ---
>> TOC <#toc>
>>
>>
>>       4.1. Assertion Attributes
>>
>> The OpenID attribute exchange service  
>> [OpenID.attribute‑exchange‑1.0] (Hardt, D., “OpenID Attribute  
>> Exchange 1.0 - Draft 03,” November 2006.) <#OpenID.attribute- 
>> exchange-1.0> is used to convey SAML assertions within an OpenID  
>> protocol session. In effect, a SAML assertion is used as an  
>> envelope to contain conventional OpenID attribute value pairs.  
>> This envelope is then assigned as a value for the SAML assertion  
>> attribute type. An attribute value that contains a SAML assertion  
>> MUST be base 64 [RFC3548] (Josefsson, S., “The Base16, Base32,  
>> and Base64 Data Encodings,” July 2003.) <#RFC3548> encoded.
>>
>> Assertion attribute names MAY be any unique identifier as outlined  
>> in [OpenID.attribute‑exchange‑1.0] (Hardt, D., “OpenID  
>> Attribute Exchange 1.0 - Draft 03,” November 2006.)  
>> <#OpenID.attribute-exchange-1.0>.
>>
>>
>> --------------------------------------------------------------------- 
>> ---
>> TOC <#toc>
>>
>>
>>       5. OpenID SAML Attribute Profile
>>
>> The OpenID Attribute Profile specifies how OpenID attributes can  
>> be represented as SAML Attributes.
>>
>> An OpenID attribute is an property value assertion that can either  
>> be self asserted or asserted by a third party. An example of a  
>> third party assertion would be a government agency aserting that  
>> Beth is older than 21. This Attribute Profile describes a OpenID  
>> attribute represented as a SAML Assertion.
>>
>>
>> --------------------------------------------------------------------- 
>> ---
>> TOC <#toc>
>>
>>
>>       5.1. Required Information
>>
>> The information given in this section is similar to the  
>> information provided when registering something, a MIME Media  
>> Type, say, with IANA. In this case, it is for registering this  
>> profile with the OASIS SSTC. See section 2 "Specification of  
>> Additional Profiles" in [OASIS.saml‑profiles‑2.0‑os] (Hughes,  
>> J., Cantor, S., Hodges, J., Hirsch, F., Mishra, P., Philpott, R.,  
>> and E. Maler, “Profiles for the OASIS Security Assertion Markup  
>> Language (SAML) V2.0,” March 2005.) <#OASIS.saml-profiles-2.0-os>.
>>
>>     Identification:
>>         TBD: urn:openid:saml-profile:attribute or
>>         http://openid.net/saml-profile/attribute     Contact  
>> Information:
>>         TBD: someone's or something's contact info goes here.      
>> Description:
>>         Given below.     Updates:
>>         None.
>>
>> --------------------------------------------------------------------- 
>> ---
>> TOC <#toc>
>>
>>
>>       5.2. SAML Attribute Naming
>>
>> The NameFormat XML attribute in <Attribute> must be  
>> urn:oasis:names:tc:SAML:2.0:profiles:attribute:uri. The Name XML  
>> attribute MUST be the OpenID attribute name and MUST adhere to the  
>> rules specified for that format. OpenID attribute names are  
>> defined in [OpenID.attribute‑exchange‑1.0] (Hardt, D.,  
>> “OpenID Attribute Exchange 1.0 - Draft 03,” November 2006.)  
>> <#OpenID.attribute-exchange-1.0>. SAML Attribute Name formats are  
>> defined in [OASIS.saml‑core‑2.0‑os] (Cantor, S., Kemp, J.,  
>> Philpott, R., and E. Maler, “Assertions and Protocol for the  
>> OASIS Security Assertion Markup Language (SAML) V2.0,” March  
>> 2005.) <#OASIS.saml-core-2.0-os>.
>>
>>
>> --------------------------------------------------------------------- 
>> ---
>> TOC <#toc>
>>
>>
>>       5.3. Profile-Specific XML Attributes
>>
>> No additional XML attributes are defined for use with the  
>> <Attribute> element.
>>
>>
>> --------------------------------------------------------------------- 
>> ---
>> TOC <#toc>
>>
>>
>>       5.4. SAML Attribute Values
>>
>> The <AttributeValue> MUST be the OpenID attribute value, as  
>> defined in [OpenID.attribute‑exchange‑1.0] (Hardt, D.,  
>> “OpenID Attribute Exchange 1.0 - Draft 03,” November 2006.)  
>> <#OpenID.attribute-exchange-1.0>.
>>
>>
>> --------------------------------------------------------------------- 
>> ---
>> TOC <#toc>
>>
>>
>>       5.5. Example
>>
>> <saml:Attribute
>>   NameFormat="urn:oasis:names:tc:SAML:2.0:profiles:attribute:uri"
>>   Name="http://openid.net/schema/contact/internet/email">
>>   <saml:AttributeValue>
>>     beth at home.com
>>   </saml:AttributeValue>
>> </saml:Attribute>
>>
>>
>> --------------------------------------------------------------------- 
>> ---
>> TOC <#toc>
>>
>>
>>       6. Assertion Schema Extension
>>
>> An OpenID attribute value may be asserted by the user or by a  
>> third-party. Third-party asserted attribute values include meta- 
>> data about the assertion in part to enable the recipient to verify  
>> the validity of the assertion. There are multiple possible ways of  
>> encoding a third-party assertion, and multiple possible ways to  
>> verify them. A SAML Assertion is one such encoding, and a digital  
>> signature is one verification mechanism.
>>
>> This section defines the particulars of how the sender, i.e. the  
>> SAML Authority, constructs certain portions of the SAML assertions  
>> it issues. The schema for SAML assertions themselves is defined in  
>> Section 2.3 of [OASIS.saml‑core‑2.0‑os] (Cantor, S., Kemp,  
>> J., Philpott, R., and E. Maler, “Assertions and Protocol for the  
>> OASIS Security Assertion Markup Language (SAML) V2.0,” March  
>> 2005.) <#OASIS.saml-core-2.0-os>.
>>
>> An example SAML assertion, formulated according to this profile is  
>> given in Section 9 (Example Signed SAML Assertion) <#example- 
>> assertion>.
>>
>> Overall SAML assertion profile requirements:
>>
>>     The SAML assertion MUST be signed by the same key as used to sign
>>     the contents of the Identity header field. Signing of SAML
>>     assertions is defined in section 5.4 of  
>> [OASIS.saml‑core‑2.0‑os]
>>     (Cantor, S., Kemp, J., Philpott, R., and E. Maler,  
>> “Assertions and
>>     Protocol for the OASIS Security Assertion Markup Language (SAML)
>>     V2.0,” March 2005.) <#OASIS.saml-core-2.0-os>.
>>
>> In the following subsections, the SAML assertion profile is  
>> specified element-by-element, in a top-down, depth-first manner,  
>> beginning with the outermost element, "<OpenIDAssertion>". This  
>> specification introduces the "<OpenIDAssertion>" element as a  
>> wrapper around the SAML "<Assertion>" element to add OpenID meta- 
>> data to the assertion. Where applicable, the requirements for an  
>> element's XML attributes are also stated, as a part of the  
>> element's description. Requirements for any given element or XML  
>> attribute are only stated when, in the context of use of this  
>> profile, they are not already sufficiently defined by  
>> [OASIS.saml‑core‑2.0‑os] (Cantor, S., Kemp, J., Philpott, R.,  
>> and E. Maler, “Assertions and Protocol for the OASIS Security  
>> Assertion Markup Language (SAML) V2.0,” March 2005.) <#OASIS.saml- 
>> core-2.0-os>.
>>
>>
>> --------------------------------------------------------------------- 
>> ---
>> TOC <#toc>
>>
>>
>>       6.1. Element openid:Assertion
>>
>>     Attribute openid:RefreshURL
>>         RefreshURL is an OPTIONAL XML attribute that, if specified,
>>         SHOULD be set to the URL where an updated assertion can be
>>         requested as per Section 8 (Refreshing an Assertion)  
>> <#refresh>.
>>
>> --------------------------------------------------------------------- 
>> ---
>> TOC <#toc>
>>
>>
>>       6.1.1. Element saml:Assertion
>>
>>     Attribute: ID
>>         The value for the ID XML attribute SHOULD be allocated
>>         randomly such that the value meets the randomness  
>> requirements
>>         specified in section 1.3.4 of [OASIS.saml‑core‑2.0‑os]
>>         (Cantor, S., Kemp, J., Philpott, R., and E. Maler,  
>> “Assertions
>>         and Protocol for the OASIS Security Assertion Markup Language
>>         (SAML) V2.0,” March 2005.) <#OASIS.saml-core-2.0-os>.      
>> Attribute: IssueInstant
>>         The value for the IssueInstant XML attribute SHOULD be set at
>>         the time the SAML assertion is created (and cached for
>>         subsequent retrieval).
>>
>> --------------------------------------------------------------------- 
>> ---
>> TOC <#toc>
>>
>>
>>       6.1.1.1. Element saml:Issuer
>>
>> If the signature contains a ds:X509Certificate, the value for the  
>> Issuer XML element SHOULD be a value that matches either the  
>> Subject or the Subject Alternative Name fields [RFC3280] (Housley,  
>> R., Polk, W., Ford, W., and D. Solo, “Internet X.509 Public Key  
>> Infrastructure Certificate and Certificate Revocation List (CRL)  
>> Profile,” April 2002.) <#RFC3280> in the certificate. The  
>> certificate element is located on this path within the SAML  
>> assertion:
>>
>> <saml:Assertion
>>   <ds:Signature
>>     <ds:KeyInfo
>>       <ds:X509Data
>>         <ds:X509Certificate
>>
>> In this case the Issuer element is in the format of the X.501 type  
>> Name.
>>
>> Assertions with signatures that do not contain an X509Certificate  
>> may use an issuer identifier that matches the ds:KeyName element  
>> (see [W3C.REC‑xmldsig‑core‑20020212] (Solo, D., Eastlake, D.,  
>> and J. Reagle, “XML-Signature Syntax and Processing,” February  
>> 2002.) <#W3C.REC-xmldsig-core-20020212>).
>>
>>
>> --------------------------------------------------------------------- 
>> ---
>> TOC <#toc>
>>
>>
>>       6.1.1.2. Element saml:Subject
>>
>> The <saml:Assertion> element MUST contain a <saml:Subject> element.
>>
>> The <saml:Subject> element MUST contain a <saml:NameID> element.
>>
>> The value of the <saml:NameID> element is a subject identifier,  
>> either a Claimed Identifier or IdP Identifier in OpenID parlance.
>>
>>
>> --------------------------------------------------------------------- 
>> ---
>> TOC <#toc>
>>
>>
>>       6.1.1.3. Element saml:Conditions
>>
>> The following XML attributes of the <saml:Conditions> element MAY  
>> be set as follows:
>>
>>     Attribute: NotBefore
>>         The value of the NotBefore XML attribute must be set to a  
>> time
>>         instant the same as the value for the IssueInstant XML
>>         attribute discussed above, or to a later time.      
>> Attribute: NotOnOrAfter
>>         The value of the NotOnOrAfter XML attribute MUST be set to a
>>         time instant later than the value for NotBefore.
>>
>> --------------------------------------------------------------------- 
>> ---
>> TOC <#toc>
>>
>>
>>       6.1.1.4. Element saml:AttributeStatement
>>
>> The SAML assertion MUST contain a single <saml:AttributeStatement>  
>> element. The <saml:AttributeStatement> element MUST contain one or  
>> more attribute-value pair, encoded according to the OpenID  
>> attribute schema extension Section 5 (OpenID SAML Attribute  
>> Profile) <#saml-attribute>. It is RECOMMENDED that the number of  
>> <saml:Attribute> elements within the <saml:AttributeStatement> be  
>> limited to one.
>>
>>
>> --------------------------------------------------------------------- 
>> ---
>> TOC <#toc>
>>
>>
>>       7. OpenID Assertion Schema
>>
>> <?xml version="1.0" encoding="UTF-8"?>
>> <!-- XML Schema for OpenIDAssertion -->
>> <schema
>>   targetNamespace="http://openid.net/xmlns/2.0"
>>   xmlns="http://www.w3.org/2001/XMLSchema"
>>   xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
>>   xmlns:openid="http://openid.net/xmlns/2.0"
>>   elementFormDefault="unqualified"
>>   attributeFormDefault="unqualified"
>>   blockDefault="substitution"
>>   version="1.0">
>>
>>   <import
>>     namespace="urn:oasis:names:tc:SAML:2.0:assertion"
>>     schemaLocation="http://docs.oasis-open.org/security/
>>                     saml/v2.0/saml-schema-assertion-2.0.xsd"/>
>>
>>   <element name="Assertion" type="openid:AssertionType"/>
>>   <complexType name="AssertionType">
>>     <sequence>
>>       <element ref="saml:Assertion" minOccurs="0" maxOccurs="1"/>
>>     </sequence>
>>     <attribute name="RefreshURL" type="anyURI" use="optional"/>
>>   </complexType>
>>
>> </schema>
>>
>>
>> --------------------------------------------------------------------- 
>> ---
>> TOC <#toc>
>>
>>
>>       8. Refreshing an Assertion
>>
>> The mechanism for refreshing an assertion based on the RefreshURL  
>> attribute of the openid:AssertionType element is not presently  
>> defined. [TBD: define refresh protocol]
>>
>> The RefreshURL attribute may be supplied by an asserting party,  
>> but SHOULD NOT be supplied to relying parties in general when it  
>> is retrieved from an identity provider. This is in keeping with  
>> the rule of minimal disclosure.
>>
>>
>> --------------------------------------------------------------------- 
>> ---
>> TOC <#toc>
>>
>>
>>       9. Example Signed SAML Assertion
>>
>> Below is an example of a signed SAML assertion:
>>
>> <openid:Assertion
>>    xmlns:openid="http://openid.net/xmlns/2.0"
>>    RefreshURL="http://example-verified-email.com/renew">
>>
>> <Assertion ID="_a75adf55-01d7-40cc-929f-dbd8372ebdfc"
>>    IssueInstant="2003-04-17T00:46:02Z" Version="2.0"
>>    xmlns="urn:oasis:names:tc:SAML:2.0:assertion">
>>    <Issuer>
>>       example-verified-email.com
>>    </Issuer>
>>    <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
>>       <ds:SignedInfo>
>>    <ds:CanonicalizationMethod
>>       Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
>>    <ds:SignatureMethod
>>       Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
>>    <ds:Reference URI="#_a75adf55-01d7-40cc-929f-dbd8372ebdfc">
>>       <ds:Transforms>
>>          <ds:Transform
>>             Algorithm=
>>             "http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
>>          <ds:Transform
>>             Algorithm=
>>             "http://www.w3.org/2001/10/xml-exc-c14n#">
>>       <InclusiveNamespaces
>>             PrefixList="#default saml ds xs xsi"
>>             xmlns=
>>             "http://www.w3.org/2001/10/xml-exc-c14n#"/>
>>          </ds:Transform>
>>       </ds:Transforms>
>>       <ds:DigestMethod
>>             Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
>>       <ds:DigestValue>
>>             Kclet6XcaOgOWXM4gty6/UNdviI=
>>       </ds:DigestValue>
>>    </ds:Reference>
>>       </ds:SignedInfo>
>>       <ds:SignatureValue>
>>         hq4zk+ZknjggCQgZm7ea8fI7...Hr7wHxvCCRwubnmIfZ6RqVL+wNmeWI4=
>>       </ds:SignatureValue>
>>       <ds:KeyInfo>
>>    <ds:X509Data>
>>        <ds:X509Certificate>
>>     MIICyjCCAjOgAwIBAgICAnUwDQYJKoZIhvcNAQEEBQAwgakxCzAJBgNVBAYTAlVT
>>     MRIwEAYDVQQIEwlXaXNjb .....  dnP6Hr7wHxvCCRwubnmIfZ6QZAv2FU78pLX
>>     8I3bsbmRAUg4UP9hH6ABVq4KQKMknxu1xQxLhpR1ylGPdiowMNTrEG8cCx3w/w==
>>        </ds:X509Certificate>
>>    </ds:X509Data>
>>       </ds:KeyInfo>
>>    </ds:Signature>
>>    <Subject>
>>       <NameID
>>         Format=
>>            "urn:oasis:names:tc:SAML:1.1:nameid-format:entity">
>>         http://www.home.com/beth
>>       </NameID>
>>    </Subject>
>>    <Conditions NotBefore="2003-04-17T00:46:02Z">
>>    </Conditions>
>>    <AttributeStatement>
>>      <Attribute
>>        NameFormat=
>>        "urn:oasis:names:tc:SAML:2.0:profiles:attribute:uri"
>>        Name="http://openid.net/schema/contact/web/blog">
>>        <AttributeValue>http://bethexample.blogspot.com</ 
>> AttributeValue>
>>     </Attribute>
>>   </AttributeStatement>
>> </Assertion>
>> </openid:Assertion>
>>
>>
>>
>> --------------------------------------------------------------------- 
>> ---
>> TOC <#toc>
>>
>>
>>       10. Security Considerations
>>
>> [NOTE: TBD]
>>
>>
>> --------------------------------------------------------------------- 
>> ---
>> TOC <#toc>
>>
>>
>>       11. Acknowledgements
>>
>> The author, John Merrels, and other contributors to the document  
>> 'draft-merrels-dix-assertion'. Portions of that document were re- 
>> used for this one.
>>
>>
>> --------------------------------------------------------------------- 
>> ---
>> TOC <#toc>
>>
>>
>>       12. References
>>
>>
>> --------------------------------------------------------------------- 
>> ---
>> TOC <#toc>
>>
>>
>>       12.1. Normative References
>>
>> [OASIS.saml-conformance-2.0-os] 	Mishra, P.  
>> <mailto:pmishra at principalidentity.com>, Philpott, R.  
>> <mailto:rphilpott at rsasecurity.com>, and E. Maler  
>> <mailto:eve.maler at sun.com>, “Conformance Requirements for the  
>> Security Assertion Markup Language (SAML) V2.0 <http://docs.oasis- 
>> open.org/security/saml/v2.0/saml-conformance-2.0-os.pdf>,” OASIS  
>> Standard saml-conformance-2.0-os, March 2005.
>> [OASIS.saml-core-2.0-os] 	Cantor, S. <mailto:cantor.2 at osu.edu>,  
>> Kemp, J. <mailto:John.Kemp at nokia.com>, Philpott, R.  
>> <mailto:rphilpott at rsasecurity.com>, and E. Maler  
>> <mailto:eve.maler at sun.com>, “Assertions and Protocol for the  
>> OASIS Security Assertion Markup Language (SAML) V2.0 <http:// 
>> docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf>,”  
>> OASIS Standard saml-core-2.0-os, March 2005.
>> [OASIS.saml-profiles-2.0-os] 	Hughes, J. <mailto:>, Cantor, S.  
>> <mailto:cantor.2 at osu.edu>, Hodges, J.  
>> <mailto:Jeff.Hodges at neustar.biz>, Hirsch, F.  
>> <mailto:Frederick.Hirsch at nokia.com>, Mishra, P.  
>> <mailto:pmishra at principalidentity.com>, Philpott, R.  
>> <mailto:rphilpott at rsasecurity.com>, and E. Maler  
>> <mailto:eve.maler at sun.com>, “Profiles for the OASIS Security  
>> Assertion Markup Language (SAML) V2.0 <http://docs.oasis-open.org/ 
>> security/saml/v2.0/saml-profiles-2.0-os.pdf>,” OASIS Standard  
>> OASIS.saml-profiles-2.0-os, March 2005.
>> [OpenID.attribute-exchange-1.0] 	Hardt, D.  
>> <mailto:dick at sxip.com>, “OpenID Attribute Exchange 1.0 - Draft  
>> 03,” November 2006 (TXT <http://www.openid.net/specs/openid- 
>> attribute-exchange-1_0-03.txt>, HTML <http://www.openid.net/specs/ 
>> openid-attribute-exchange-1_0-03.html>).
>> [OpenID.authentication-2.0] 	Recordon, D.  
>> <mailto:drecordon at verisign.com>, Hoyt, J.  
>> <mailto:josh at janrain.com>, Fitzpatrick, B.  
>> <mailto:brad at danga.com>, and D. Hardt <mailto:dick at sxip.com>,  
>> “OpenID Authentication 2.0 - Draft 10,” August 2006 (TXT  
>> <http://www.openid.net/specs/openid-authentication-2_0-10.txt>,  
>> HTML <http://www.openid.net/specs/openid- 
>> authentication-2_0-10.html>).
>> [RFC2119] 	Bradner, S. <mailto:sob at harvard.edu>, “Key words for  
>> use in RFCs to Indicate Requirement Levels <ftp://ftp.isi.edu/in- 
>> notes/rfc2119.txt>,” BCP 14, RFC 2119, March 1997 (TXT <ftp:// 
>> ftp.isi.edu/in-notes/rfc2119.txt>, HTML <http://xml.resource.org/ 
>> public/rfc/html/rfc2119.html>, XML <http://xml.resource.org/public/ 
>> rfc/xml/rfc2119.xml>).
>> [RFC3280] 	Housley, R., Polk, W., Ford, W., and D. Solo,  
>> “Internet X.509 Public Key Infrastructure Certificate and  
>> Certificate Revocation List (CRL) Profile <ftp://ftp.isi.edu/in- 
>> notes/rfc3280.txt>,” RFC 3280, April 2002.
>> [RFC3548] 	Josefsson, S., “The Base16, Base32, and Base64 Data  
>> Encodings <ftp://ftp.isi.edu/in-notes/rfc3548.txt>,” RFC 3548,  
>> July 2003.
>> [W3C.REC-xmldsig-core-20020212] 	Solo, D., Eastlake, D., and J.  
>> Reagle, “XML-Signature Syntax and Processing <http://www.w3.org/ 
>> TR/2002/REC-xmldsig-core-20020212>,” W3C Recommendation http:// 
>> www.w3.org/TR/2002/REC-xmldsig-core-20020212, February 2002.
>>
>>
>> --------------------------------------------------------------------- 
>> ---
>> TOC <#toc>
>>
>>
>>       12.2. Informative References
>>
>> [OASIS.saml-glossary-2.0-os] 	Hodges, J.  
>> <mailto:Jeff.Hodges at neustar.biz>, Philpott, R.  
>> <mailto:rphilpott at rsasecurity.com>, and E. Maler  
>> <mailto:eve.maler at sun.com>, “Glossary for the Security Assertion  
>> Markup Language (SAML) V2.0 <http://docs.oasis-open.org/security/ 
>> saml/v2.0/saml-glossary-2.0-os.pdf>,” OASIS Standard saml- 
>> glossary-2.0-os, March 2005.
>> [OpenID.attribute-types-1.0] 	Hardt, D. <mailto:dick at sxip.com>,  
>> “OpenID Attribute Types - Draft 02,” November 2006 (TXT <http:// 
>> www.openid.net/specs/openid-attribute-types-1_0-02.txt>, HTML  
>> <http://www.openid.net/specs/openid-attribute-types-1_0-02.html>).
>>
>>
>> --------------------------------------------------------------------- 
>> ---
>> TOC <#toc>
>>
>>
>>       Author's Address
>>
>> 	Dick Hardt
>> 	Sxip Identity
>> 	798 Beatty Street
>> 	Vancouver, BC V6B 2M1
>> 	CA
>> Email: 	dick at sxip.com <mailto:dick at sxip.com>
>> URI: 	http://sxip.com/
>>
>> --------------------------------------------------------------------- 
>> ---
>>
>> _______________________________________________
>> specs mailing list
>> specs at openid.net
>> http://openid.net/mailman/listinfo/specs
>>    
>> --------------------------------------------------------------------- 
>> ---
>>
>> No virus found in this incoming message.
>> Checked by AVG Free Edition.
>> Version: 7.1.409 / Virus Database: 268.15.6/566 - Release Date:  
>> 12/3/2006
>>
>
> -- 
> Paul Madsen             e:paulmadsen @ ntt-at.com
> NTT                     p:613-482-0432
>                        m:613-302-1428
>                        aim:PaulMdsn5
>                        web:connectid.blogspot.com
>  TOC
> DraftP. Madsen
>  NTT
>  ELM. Maler
>  Sun
>  November 29, 2006
>
> SAML OpenID Simple Registration Attribute Profile - Draft 1 Abstract
> This document defines an attribute profile for SAML V2.0 for  
> OpenID's Simple Registration Extension 1.0. It defines how the  
> profile attributes defined in the OpenID Simple Registration  
> Extension can be carried in SAML attributes
>
>
> Table of Contents
> 1  Requirements Notation
> 2  Introduction
> 3  SAML OpenID Simple Registration Attribute Profile
>     3.1  Information
>     3.2  SAML Attribute Naming
>     3.3  Profile-Specific XML Attributes
>     3.4  SAML Attribute values
> 4  Example
> 5  Normative References
> §  Authors' Addresses
>
>
> 1  Requirements Notation
> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",  
> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in  
> this document are to be interpreted as described in [RFC2119]  
> (Bradner, B., “Key words for use in RFCs to Indicate Requirement  
> Levels,” ?.) .
>
> 2  Introduction
> This document defines an attribute profile for SAML V2.0 for the  
> [OpenIDSimpleReg] (Hoyt, J., Daugherty, J., and D. Recordon,  
> “OpenID Simple Registration Extension v1,” 2006.)
>
> The OpenID Simple Registration Extension extends the OpenID  
> Authentication Protocol to allow for lightweight profile exchange.  
> This attribute profile specifies how the profile attributes defined  
> there can be passed as SAML attributes within SAML protocol messages.
>
> 3  SAML OpenID Simple Registration Attribute Profile 3.1  Information
> Identification: http://www.xmlgrrl.com/ns/OpenIDSimpleReg  
> (provisionally!)
>
> Contact information: paul.madsen at gmail.com, eve.maler at sun.com
>
> 3.2  SAML Attribute Naming
> The NameFormat XML attribute in <Attribute> elements MUST be  
> "http://openid.net/specs/openid-simple-registration- 
> extension-1_0.html"
>
> The Name XML attribute MUST be the field name as defined in  
> [OpenIDSimpleReg] (Hoyt, J., Daugherty, J., and D. Recordon,  
> “OpenID Simple Registration Extension v1,” 2006.).
>
> 3.3  Profile-Specific XML Attributes
> No profile specific XML attributes are defined in this profile.
>
> 3.4  SAML Attribute values
> The <AttributeValue> MUST be the field value, as defined in  
> [OpenIDSimpleReg] (Hoyt, J., Daugherty, J., and D. Recordon,  
> “OpenID Simple Registration Extension v1,” 2006.)
>
> 4  Example
> Example of a SAML Attribute
>
> joecool at snoopy.com
>
>  TOC
> 5. Normative References
> [OpenIDSimpleReg]Hoyt, J., Daugherty, J., and D. Recordon, “OpenID  
> Simple Registration Extension v1,” 2006.
> [RFC2119]Bradner, B., “Key words for use in RFCs to Indicate  
> Requirement Levels,” RFC 2119, ?.
>
>  TOC
> Authors' Addresses
>  Paul Madsen
>  NTT
> Email: paul.madsen at gmail.com
>
>  Eve Maler
>  Sun Microsystems, Inc.
> Email: eve.maler at sun.com
> <?xml version="1.0" encoding="UTF-8"?>
> <?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
> <!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
>
> <!ENTITY rfc2119 PUBLIC " " "http://xml.resource.org/public/rfc/ 
> bibxml/reference.RFC.2119.xml" >
>
> ]>
>
> <rfc category="info" ipr="none" docName="temp.xml">
>
>   <?rfc toc="yes" ?>
>   <?rfc tocdepth="2" ?>
>   <?rfc symrefs="yes" ?>
>   <?rfc sortrefs="yes"?>
>   <?rfc iprnotified="no" ?>
>   <?rfc strict="yes" ?>
>   <?rfc private="Draft" ?>
>
>   <front>
>     <title abbrev="SAML">SAML OpenID Simple Registration Attribute  
> Profile - Draft 1</title>
>
>     <author initials="P.M" surname="Madsen" fullname="Paul Madsen">
>       <organization abbrev="NTT">NTT</organization>
>       <address>
>         <email>paul.madsen at gmail.com</email>
>       </address>
>     </author>
>
>     <author initials="ELM" surname="Maler" fullname="Eve Maler">
>       <organization abbrev="Sun">Sun Microsystems, Inc.</organization>
>       <address>
>         <email>eve.maler at sun.com</email>
>       </address>
>     </author>
>
>     <date month="November" year="2006"/>
>
>     <abstract>
>       <t>
> 	This document defines an attribute profile for SAML V2.0 for OpenID's
> Simple Registration Extension 1.0.  It defines how the profile
> attributes defined in the OpenID Simple Registration Extension can be
> carried in SAML attributes
>       </t>
>
>     </abstract>
>   </front>
>
>   <middle>
>     <section title="Requirements Notation">
>       <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
>       "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
>       and "OPTIONAL" in this document are to be interpreted as
>       described in <xref target="RFC2119"/> .</t>
>     </section>
>
>     <section title="Introduction ">
>
>       <t>
>        This document defines an attribute profile for
>        SAML V2.0 for the <xref target="OpenIDSimpleReg"/>
>       </t>
>
>       <t>
>        The OpenID Simple Registration Extension extends the OpenID  
> Authentication Protocol to allow
> for lightweight profile exchange. This attribute profile specifies
> how the profile attributes defined there can be passed as SAML
> attributes within SAML protocol messages.
>       </t>
>
>     </section>
>
>     <section title="SAML OpenID Simple Registration Attribute  
> Profile">
>
>        <section title="Information">
>
> <t>Identification: http://www.xmlgrrl.com/ns/OpenIDSimpleReg  
> (provisionally!)</t>
> <t>Contact information: paul.madsen at gmail.com, eve.maler at sun.com</t>
>
>        </section>
>
>        <section title="SAML Attribute Naming">
>
>         <t>The NameFormat XML attribute in &lt;Attribute&gt;  
> elements MUST be "http://openid.net/specs/openid-simple- 
> registration-extension-1_0.html"</t>
>
>         <t>The Name XML attribute MUST be the field name as defined  
> in <xref target="OpenIDSimpleReg"/>.</t>
>
>        </section>
>
>        <section title="Profile-Specific XML Attributes">
>
>         <t>No profile specific XML attributes are defined in this  
> profile.</t>
>        </section>
>
>        <section title="SAML Attribute values">
>
>         <t>The &lt;AttributeValue&gt; MUST be the field value, as  
> defined in <xref target="OpenIDSimpleReg"/></t>
>
>        </section>
>
>     </section>
>
>     <section title="Example">
> 	  <figure>
> 	    <preamble>
> 	   Example of a SAML Attribute
> 	    </preamble>
> <artwork><![CDATA[
> <saml:Attribute
>     NameFormat="http://openid.net/specs/openid-simple-registration- 
> extension-1_0.html"
>     Name="openid.sreg.email">
>   <saml:AttributeValue>
>     joecool at snoopy.com
>   </saml:AttributeValue>
> </saml:Attribute>]]></artwork>
> 	  </figure>
>     </section>
>   </middle>
>
>   <back>
>     <references title='Normative References'>
>       <reference anchor='RFC2119'>
>         <front>
>           <title>
>             Key words for use in RFCs to Indicate Requirement Levels
>           </title>
>           <author initials='B.S' surname='Bradner' fullname='Scott  
> Bradner'>
>             <organization>Alis Technologies</organization>
>           </author>
>           <date year="?"/>
>         </front>
>         <seriesInfo name="RFC" value="2119" />
>       </reference>
>
>
>       <reference anchor="OpenIDSimpleReg">
> 	<front>
> 	  <title>OpenID Simple Registration Extension v1</title>
>
> 	  <author initials="J.H" surname="Hoyt" fullname="Josh Hoyt">
> 	    <organization abbrev="JanRain">JanRain</organization>
> 	  </author>
>
> 	  <author initials="J.D" surname="Daugherty" fullname="J. Daugherty">
> 	    <organization abbrev="JanRain">JanRain, Inc.</organization>
> 	  </author>
>
> 	  <author initials="D.R" surname="Recordon" fullname="David  
> Recordon">
> 	    <organization abbrev="VeriSign">VeriSign, Inc.</organization>
> 	  </author>
>
> 	  <date year="2006"/>
> 	</front>
> 	<format type='HTML' target='http://openid.net/specs/openid-simple- 
> registration-extension-1_0.html'/>
>       </reference>
>
>
>
>     </references>
>   </back>
> </rfc>




More information about the specs mailing list