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.
_______________________________________________
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs
