<HTML dir=ltr><HEAD></HEAD>
<BODY>
<DIV id=idOWAReplyText46947 dir=ltr>
<DIV dir=ltr><FONT face=Arial color=#000000 size=2>is a protocol extension always the right place to address the issue? (*)</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>Another way of thinking is to enhance YADIS - and leverage signed meta-assertions within the XRDs that "qualify' the service endpoints, for use by those RPs who care enough to parse these extra "endpoint-qualifer statements"</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>Rather than be RSA signed (given RSA signatures seem to jarr with the OpenID community), the blob could be symmetrically signed on the fly, in the manner of cardspace tokens.</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>(*) It may have fallen of the IESG track, but there was also a proposal last year to leverage a new TLS record layer protocol so it too would convey control/qualification statements. A signature issued by the webserver supported by https provided specifically by front-end loadbalancers allowed the client to have assurance that the loadbalancer (doing openid auth-style assertion issuing) properly speaks for the webapp. Under IETF rules, the patent issues regarding these techniques were (forcibly) disclosed. Nice modern prior art disclosues happened, as a consequence.</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial color=#000000 size=2><SPAN style="FONT-SIZE: 7.5pt">_________________________<BR></SPAN><B>Peter Williams<BR></B></FONT><BR>
<HR tabIndex=-1>
<FONT face=Tahoma size=2><B>From:</B> Nat Sakimura<BR><B>Sent:</B> Thu 5/15/2008 2:10 AM<BR><B>To:</B> Martin Paljak<BR><B>Cc:</B> OpenID General<BR><B>Subject:</B> Re: [OpenID] Configuration file for OpenID libraries?<BR></FONT><BR></DIV></DIV>
<DIV><PRE style="WORD-WRAP: break-word">I agree that these would be useful. At the same time however, I feel
that creating something like "Reputation Service Extension" to the
OpenID spec. so that sites are able to filter dynamically is better
than ad hoc static filtering using white and black list. I think it
fits the "Openness" philosophy of OpenID better as well.
On Thu, May 15, 2008 at 2:11 PM, Martin Paljak <martin@paljak.pri.ee> wrote:
> Hi.
>
> Currently OpenID libraries (for RP-s) seem to provide language
> bindings for low level openid protocol handling and all 'interesting
> stuff' is done by the programmer doing the integration. As OpenID gets
> merged into more opensource webapp packages, it might be useful to
> provide a configuration file that is common across implementations and
> allows to declare some "common" authorization bits:
>
> * whitelist: <regexp>
> * blacklist: <regexp>
> * fingerprint: <OP domain>:<OP SSL cert fingerprint>
>
> I'd like to know what the community thinks about the overall idea and
> the given authorization steps.
>
> m.
> --
> Martin Paljak
> http://martin.paljak.pri.ee
> GSM: +3725156495
>
>
>
>
> _______________________________________________
> general mailing list
> general@openid.net
> http://openid.net/mailman/listinfo/general
>
--
Nat Sakimura (=nat)
http://www.sakimura.org/en/
_______________________________________________
general mailing list
general@openid.net
http://openid.net/mailman/listinfo/general
</PRE></DIV></BODY></HTML>