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 [EMAIL PROTECTED] >> >> >> --------------------------------------------------------------------- >> --- >> 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> >> [EMAIL PROTECTED] >> </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:[EMAIL PROTECTED]>, Philpott, R. >> <mailto:[EMAIL PROTECTED]>, and E. Maler >> <mailto:[EMAIL PROTECTED]>, “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:[EMAIL PROTECTED]>, >> Kemp, J. <mailto:[EMAIL PROTECTED]>, Philpott, R. >> <mailto:[EMAIL PROTECTED]>, and E. Maler >> <mailto:[EMAIL PROTECTED]>, “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:[EMAIL PROTECTED]>, Hodges, J. >> <mailto:[EMAIL PROTECTED]>, Hirsch, F. >> <mailto:[EMAIL PROTECTED]>, Mishra, P. >> <mailto:[EMAIL PROTECTED]>, Philpott, R. >> <mailto:[EMAIL PROTECTED]>, and E. Maler >> <mailto:[EMAIL PROTECTED]>, “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:[EMAIL PROTECTED]>, “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:[EMAIL PROTECTED]>, Hoyt, J. >> <mailto:[EMAIL PROTECTED]>, Fitzpatrick, B. >> <mailto:[EMAIL PROTECTED]>, and D. Hardt <mailto:[EMAIL PROTECTED]>, >> “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:[EMAIL PROTECTED]>, “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:[EMAIL PROTECTED]>, Philpott, R. >> <mailto:[EMAIL PROTECTED]>, and E. Maler >> <mailto:[EMAIL PROTECTED]>, “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:[EMAIL PROTECTED]>, >> “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: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> >> URI: http://sxip.com/ >> >> --------------------------------------------------------------------- >> --- >> >> _______________________________________________ >> specs mailing list >> [email protected] >> 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: [EMAIL PROTECTED], [EMAIL PROTECTED] > > 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 > > [EMAIL PROTECTED] > > 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: [EMAIL PROTECTED] > > Eve Maler > Sun Microsystems, Inc. > Email: [EMAIL PROTECTED] > <?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>[EMAIL PROTECTED]</email> > </address> > </author> > > <author initials="ELM" surname="Maler" fullname="Eve Maler"> > <organization abbrev="Sun">Sun Microsystems, Inc.</organization> > <address> > <email>[EMAIL PROTECTED]</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: [EMAIL PROTECTED], [EMAIL PROTECTED]</t> > > </section> > > <section title="SAML Attribute Naming"> > > <t>The NameFormat XML attribute in <Attribute> > 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 <AttributeValue> 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> > [EMAIL PROTECTED] > </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> _______________________________________________ specs mailing list [email protected] http://openid.net/mailman/listinfo/specs
