OpenID Signed Assertions 1.0 - Draft 1

[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 group                Sun Microsystems, Inc.