No subject
Fri Feb 8 18:42:25 UTC 2008
r proxies in its protocol. If this conversation were in the context of suc=
h support or a stronger trust model, we'd have something to talk about, and=
you hint at that in your last paragraph. =20
Until there are reputation services or federations or something, ultimate a=
ccess control decisions are solely the SP/RP's to make. It alone must deci=
de how to trust the inputs. There's just nothing else to go by.
Hope this makes sense,
Nate.
--Apple-Mail-118-30880233
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset="iso-8859-1"
<HTML dir=3Dltr><HEAD></HEAD>
<BODY style=3D"WORD-WRAP: break-word; -webkit-nbsp-mode: space; -webkit-lin=
e-break: after-white-space">
<DIV id=3DidOWAReplyText24024 dir=3Dltr>
<DIV dir=3Dltr><FONT face=3DArial size=3D2>Interestingly, the term access (=
as in access control) only appears once in <A href=3D"http://openid.net/spe=
cs/openid-authentication-2_0.html" target=3D_blank>http://openid.net/specs/=
openid-authentication-2_0.html</A> - and its used in a negative clause=
, at that.</FONT></DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2>The only use of trust is in the =
context of the terms trust_root and realm. I *know* I don't understand the =
theory of the protocol and its signal handling requirements in these areas.=
I suspect the designers have again shifted the goals posts, aiming for a p=
aradigm shift (even if it is a paradigm "revisited"). For example, the natu=
re of trust_root appears to be tied up with the notion of releasing a=
different ClaimedID per user and Sreg attribute set (and possibly a differ=
ent claimedID per user session) to each RP site or RP subsite (where subsit=
es controls support the "hosted RP" world). And this apparently goes to the=
whole crux of the directed identity law and the notion of privacy control =
(in a UCI model) If I now cast it all in terms I do understand, leavi=
ng the directed identity twist aside, its all playing with similar ideas th=
at SSL/https addressed , when a server's X.509 cert's CN field has *.verisi=
gn.com as wildcarded reliance pattern, affecting how sites applying inbound=
Host-Headers would or could not act as authorized SSL endpoints for those =
virtual-hosting sites.</FONT></DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2>Trust - as in the traditional an=
d endless discussion of authorization, access control, key management, auth=
ority to assert, delegation models, (X.518 chaining models for X.511 s=
igned DAP assertions passing across naming contexts) - seems almost un=
OpenID. </FONT><FONT face=3DArial size=3D2>The notion of trust is however u=
sed in a specific way - as embodied in the phrase.. "URL pattern the OP SHO=
ULD ask the end user to _trust_".</FONT></DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2>Given that the trust notion is v=
ery much tied to using the web and SSL certs as a giant name server, and gi=
ven that XRIs are OpenIDs, and given XRI has very specific authority and au=
thority-delegation models that will impact such URI patterns in the handler=
s addressing "naming realms", I'm not sure that its appropriate to say that=
OpenID (v2) has a "lightweight" trust model. Lightweight may have bee=
n true descriptor for OpenID1, I'd grant you that. But in OpenID2 + XRI, we=
have anything but lightweight. Don't we now have a full power authority-re=
volver (and name-revolver) infrastructure built into every conforming =
OpenID2 RP? One only has to look at the uses of wildcard XRIs in the XRDs f=
rom i-name servers accessed via YADIS (or HXRIs) to get a feel for what's g=
oing on, here.</FONT></DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2>Now what is interesting is that =
the term trust seems to be being reserved for use only in that authori=
ty/name revolver context. Reputation is entirely a different issue, disting=
uished from trust (as above) and is of course a Work in Progress. One day, =
Ill break my rule, and go sneak a peek at the various WG drafts on these "a=
dditional areas of ongoing normalization".</FONT></DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2>I think we are just starting to =
discover the explicit trust model and the explicit authority/del=
egation model built already into OpenID2 Auth. Rather than be tied to proxy=
chaining (as in X.518 and SAML2 protocol-level chaining controls), its tie=
d to naming context delegation (as in X501 <A href=3D"http://sec.cs.kent.ac=
.uk/x500book/Chapter.4/Chapter4.htm#4.5%20DISTRIBUTED%20NAME%20RESOLUTION" =
target=3D_blank>http://sec.cs.kent.ac.uk/x500book/Chapter.4/Chapter4.htm#4.=
5%20DISTRIBUTED%20NAME%20RESOLUTION</A>)</FONT></DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV dir=3Dltr>Peter</DIV></DIV>
<DIV dir=3Dltr><BR>
<HR tabIndex=3D-1>
<FONT face=3DTahoma size=3D2><B>From:</B> Nate Klingenstein<BR><B>Sent:</B>=
Sun 4/13/2008 1:33 PM<BR><B>To:</B> Peter Williams<BR><B>Cc:</B> general at o=
penid.net<BR><B>Subject:</B> Re: [OpenID] Supporting OpenID<BR></FONT><BR><=
/DIV>
<DIV>Peter,=20
<DIV>
<DIV><BR class=3DApple-interchange-newline>
<BLOCKQUOTE type=3D"cite">
<DIV id=3DidOWAReplyText38798 dir=3Dltr>
<DIV dir=3Dltr><FONT face=3DArial color=3D#000000 size=3D2>I think its germ=
ane to address the apparently sensitive issue at the heart of the thread: g=
atewaying, particularly in this highly doctrinal UCI forum.</FONT></DIV></D=
IV></BLOCKQUOTE>
<DIV><BR></DIV>
<DIV>I don't think it's relevant because there's a lightweight trust model =
here. I receive and validate an identifier from this OP. I=
make a decision how to trust it. I may decide that it's "equivalent"=
to a Google account, or I may not, but that's totally independent. I=
t'd still be independent if this were a google.com address(all kinds of int=
eresting things happen in *.edu domains).</DIV>
<DIV><BR class=3Dwebkit-block-placeholder></DIV>
<DIV>From my brief reading, OpenID doesn't have any formal notions of gatew=
ays or proxies in its protocol. If this conversation were in the cont=
ext of such support or a stronger trust model, we'd have something to talk =
about, and you hint at that in your last paragraph. </DIV>
<DIV><BR class=3Dwebkit-block-placeholder></DIV>
<DIV>Until there are reputation services or federations or something, =
ultimate access control decisions are solely the SP/RP's to make. It =
alone must decide how to trust the inputs. There's just nothing else =
to go by.</DIV>
<DIV><BR class=3Dwebkit-block-placeholder></DIV>
<DIV>Hope this makes sense,</DIV>
<DIV>Nate.</DIV>
<BLOCKQUOTE type=3D"cite">
<DIV id=3DidOWAReplyText38798 dir=3Dltr>
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT></DIV></DIV></BLOCKQUOTE>=
</DIV></DIV></DIV></BODY></HTML>
--Apple-Mail-118-30880233--
More information about the general
mailing list