Re: OpenID Signed Assertions 1.0 - Draft 1

2006-12-04 Thread Paul Madsen
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

Re: OpenID Signed Assertions 1.0 - Draft 1

2006-12-04 Thread Eve L. Maler
Hi folks-- There certainly seems to be some convergentness in the 
air here!  Below is a very quick analysis/comparison of the two 
docs.  Hopefully some of us can discuss in detail in person this week...

I'm intrigued by the use in Dick's profile of ...:entity as the 
NameID Format for OpenID URLs (and presumably XRIs too?).  I've been 
discussing this this general topic with some folks but hadn't 
alighted on that as a possibility.  To be honest, I'd been thinking 
that a new NameID Format should be invented, to indicate that the 
entity is a URI-based identifier, once dereferenced, is prepared to 
offer OpenID-compliant metadata in the form of YADIS or XRDS -- 
which is more than just saying it's a random web entity.  (If XRIs 
need to be distinguished still further, a NameID Format of 
xri://$xri for them might be appropriate.)

As for how you encode OpenID-specific attributes, Paul and I 
retained the original string format of the Simple Registration 
fields (like so: openid.sreg.email) by virtue of inventing a new 
Attribute NameFormat that points to the Simple Reg spec, and it 
looks like Dick uses URIs directly for attribute names (I'm not sure 
if the email semantic he's referring to comes from Simple Reg or 
somewhere else).  Either style works for me, as long as any 
OpenID-specific semantics are part of the attribute name format 
definition.

I have to study Dick's spec a bit more, but I suspect that it might 
benefit from factoring out -- different profiling topics separated 
out into separate specs so that they can be used across a variety of 
existing SAML use cases.  E.g., doing the NameID Format piece 
separately means that you can immediately convey OpenIDs as subject 
identifiers in arbitrary SAML protocols and profiles, and doing the 
attribute profile piece separately (which is all Paul and I tackled) 
means you can immediately convey OpenID-flavored attributes in the 
various existing protocols and profiles that involve attributes. 
These would be applicable across all the relevant bindings for the 
existing SAML profiles, of course (POST, redirect, artifact...). 
 From this vantage point, we could then see where other additions 
might be warranted (doing an attribute-refreshing protocol and 
matching profile that specifically call out the lower-level name ID 
and attribute profiles?).

Eve

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
-- 
Eve Maler +1 425 947 4522
Technology Director   eve.maler @ sun.com
CTO Business Alliances groupSun Microsystems, Inc.
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs