[OIDFSC] OpenID v.Next Discovery Working Group Proposal

Brian Kissel bkissel at janrain.com
Mon May 24 16:56:53 UTC 2010


What is the cost? The Tech Committee has some budget.

Cheers,

Brian
___________

Brian Kissel
CEO - JanRain, Inc.
bkissel at janrain.com
Mobile: 503.342.2668 | Fax: 503.296.5502
519 SW 3rd Ave. Suite 600  Portland, OR 97204

Increase registrations, engage users, and grow your brand with RPX.  Learn
more at www.rpxnow.com


-----Original Message-----
From: openid-specs-bounces at lists.openid.net
[mailto:openid-specs-bounces at lists.openid.net] On Behalf Of Nat Sakimura
Sent: Monday, May 24, 2010 8:05 AM
To: Johannes Ernst
Cc: OpenID Specs Mailing List
Subject: Re: [OIDFSC] OpenID v.Next Discovery Working Group Proposal

Good idea.

I can setup a project under bitbucket.org/openid/ (shall we upgrade to
non-free version
so that we get it under openid.net?) and it has a rudimentary bug
tracking system.
It can be used by logging in by OpenID.

=nat

On Mon, May 24, 2010 at 11:50 AM, Johannes Ernst
<jernst+openid.net at netmesh.us> wrote:
> Allen, combining what you just wrote with what Brian said on the board
> mailing list about MRDs -- perhaps it would make sense to set up a "bug
> tracking system" of some kind and use that to drive spec evolution?
> On May 23, 2010, at 18:56, Allen Tom wrote:
>
> Hi Johannes,
>
> There isn't a document summarizing the deficiencies with OpenID 2.0
> discovery - I think it would be very useful for the WG and for the
Community
> if we wrote this down
>
> Off the top of my head, some of the problems are:
>
> Yadis discovery is very vague as to exactly how the RP is supposed to
fetch
> the OP's discovery document. Should it send the magic Accept header?
Look
> for the X-XRDS-Location header in the response? Do HTML discovery? In
> practice, many implementers have had problems implementing discovery
because
> there are too many ways to do it
> Speaking of Yadis, the specs need to be revised, and it's unclear how to
go
> about doing this
> Because a compromised discovery document can result in the complete
> breakdown in OpenID security - it's important that we find ways to
increase
> the security of discovery - perhaps it can be signed? Moved into DNS?
> Discovery is hard to implement - the majority of the code in OpenID
> libraries is to implement discovery. We can probably simplify discovery
to
> require less code to implement
> Delegation is a really useful feature in OpenID - it was pretty
> straightforward in OpenID 1.1, but is very confusing (to say the least)
in
> OpenID 2.0 - we can probably do something in discovery to make
delegation
> work better
> The infamous NASCAR problem could possibly be helped by discovery
> The infamous phishing problem could also possibly be helped by discovery
> LRDD, host-meta, and webfinger are pretty interesting - we should see
how
> OpenID can leverage these new specs
>
> I'm sure that there are more issues with OpenID 2.0 discovery. Anyone
else
> want to take a stab at it?
>
> Allen
>
>
> On 5/21/10 7:55 PM, "Johannes Ernst" <jernst+openid.net at netmesh.us>
wrote:
>
> On May 21, 2010, at 19:28, Allen Tom wrote:
>
> ... there's universal consensus that the existing OpenID 2.0 discovery
> mechanism is very deficient ...
>
> Is there a summary somewhere of this "universal consensus" of
deficiencies?
>
> Thanks,
>
>
> Johannes Ernst
> NetMesh Inc.
>
>
>
>
>
>
> _______________________________________________
> specs mailing list
> specs at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs
>
>



-- 
Nat Sakimura (=nat)
http://www.sakimura.org/en/
http://twitter.com/_nat_en
_______________________________________________
specs mailing list
specs at lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-specs


More information about the specs mailing list