Re: [apps-discuss] Webfinger goals doc

[Joseph Holsten <[e-mail]>]

Kingsley,

Are you telling us you've implemented a custom PKI outside the de-facto web CA structure? And it isn't just use TLS with custom web-of-trust network for cert verification?

Because from my perspective, the best authority chain I can expect from an in-browser JS client is from ye olde web CAs. And if we allow HTTP-sans-TLS, we can't even guarantee that. 


--
http://josephholsten.com

On Nov 29, 2012, at 14:44, Kingsley Idehen <[e-mail]> wrote:

> On 11/29/12 5:31 PM, John Panzer wrote:
>> It's Bob's entire public identity.  Knowing it wasn't altered in transit or served from a take origin is kind of...         important.
>> 
> 
> You have to distinguish "profile discovery" from "profile authenticity" esp., when dealing with nebulous identity and profile oriented matters. This is the point I believe Blaine is alluding to in his comments re. separation of powers. 
> 
> HTTPS doesn't ensure authenticity on it own, the entire CA network has been long compromised. You really need to add logic into the structured data i.e., via machine-readable entity relationship semantics to truly address this problem. Thus, for sake of getting     Webfinger to a critical beachhead, best to keep these matters separate. 
> 
> Disclosure: We already have Webfinger working in scenarios where     Identity verification and profile claims authenticity are the focal point. This all happened without making any change requests re. the current Webfinger spec :-) 
> 
> Kingsley 
>> On Nov 29, 2012 12:17 PM, "Paul E. Jones" <[e-mail]> wrote:
>>> The example in section 4.1 is a good example.
>>> 
>>>  
>>> 
>>> Every single bit of information is served over HTTP.  Bob’s blog, Bob’s vcard info, Bob’s profile page, etc.  It’s all public information.
>>> 
>>>  
>>> 
>>> There are only certain applications where HTTPS is vital.  Even OpenID 2.0 does not need HTTPS, really. If I had my OpenID Provider endpoint URL in WF and somebody changed the value when I tried to access the service, I would know when the window opened that it’s not the correct site.  My OpenID login URL (https://openid.packetizer.com/login/) would present a page when I log in that I could clearly identify as bogus.
>>> 
>>>  
>>> 
>>> Still, use of TLS might be preferred for OpenID 2.0 just to help prevent a situation where the user is not paying attention to the fact they were redirected to a phishing site.  So, I’m not arguing against use of TLS for OpenID 2.0 or OpenID Connect.  I’m only saying that there are only certain uses of WF that truly need it.  If WF is only use for stuff like in Section 4.1, TLS is not needed.
>>> 
>>>  
>>> 
>>> Paul
>>> 
>>>  
>>> 
>>> From: [e-mail]                         [mailto:[e-mail]] On Behalf Of John Panzer
>>> Sent: Thursday, November 29, 2012 3:08 PM
>>> To: [e-mail]
>>> Cc: Joseph Holsten; [e-mail]
>>> Subject: Re: [apps-discuss] Webfinger goals doc
>>> 
>>>  
>>> 
>>> On Thu, Nov 29, 2012 at 11:47 AM, Paul E. Jones <[e-mail]> wrote:
>>> 
>>> There are useful applications of WF where HTTPS is not needed.
>>> 
>>>  
>>> 
>>> Could we list those?  I'm having trouble coming up with any myself that aren't something like a localhost loopback for testing, frankly.
>>> 
>>>  
>>> 
>>>  
>>> 
>>>  At the same
>>> time, there is absolutely nothing to prevent an OpenID Connect client from
>>> only using TLS.  In fact, I would make that a requirement in OpenID Connect.
>>> 
>>> 
>>> Paul
>>> 
>>> > -----Original Message-----
>>> > From: [e-mail] [mailto:apps-discuss-
>>> 
>>> > [e-mail]] On Behalf Of Joseph Holsten
>>> > Sent: Thursday, November 29, 2012 1:53 PM
>>> > To: [e-mail]; [e-mail]
>>> > Subject: Re: [apps-discuss] Webfinger goals doc
>>> >
>>> > Show of hands, who's saying we should support http-sans-tls?
>>> >
>>> > Didn't we agree that supporting small providers was not a goal? I
>>> > seriously can't think of a situation where any site that offers accounts
>>> > to the public should not be expected to run https.
>>> >
>>> > Clearly big fish and motivated vanity domain folks will make it work.
>>> >
>>> > --
>>> > http://josephholsten.com
>>> >
>>> > On Nov 29, 2012, at 10:18, Breno de Medeiros <[e-mail]>                               wrote:
>>> >
>>> > > On Thu, Nov 29, 2012 at 9:41 AM, John Bradley <[e-mail]>
>>> > wrote:
>>> > >> Blaine,
>>> > >>
>>> > >> You may be right and openID should not be trying to use WF.
>>> > >
>>> > > + 1
>>> > >
>>> > >>
>>> > >> There was a lot of pressure put on the two groups to avoid having two
>>> > >> discovery protocols.
>>> > >
>>> > > Yes, and my objective here was                               to clarify the implications of doing
>>> > > so. With the current write up, it's not feasible to use WF in an authz
>>> > > context.
>>> > >
>>> > >>
>>> > >> As I have said several times, adding the additional requirements for
>>> > >> security to WF may be breaking it for its original more FoF like
>>> > purpose.
>>> > >>
>>> > >> Connect's use case for discovery ls simply finding the IdP
>>> > >> relationship for a identifier the user gives to a RP securely to
>>> > prevent phishing.
>>> > >> We could extract the domain and do a simple https://  GET to the
>>> > >> .well-known/openid-configuration.
>>> > >>
>>> > >> All the other stuff in WF is extraneous to us.  Using WF to let a
>>> > >> host provide per account delegation of IdP services is nice in
>>> > >> theory, but may windup compromising both protocols.
>>> > >
>>> > > More is less for security.
>>> > >
>>> > > Let's give up on the goal of re-using WF for OpenIDConnect and allow
>>> > > WF to converge to a solution that is more suitable to its specified
>>> > > goals.
>>> > >
>>> > >>
>>> > >> John B.
>>> > >>
>>> > >> On 2012-11-29, at 2:24 PM, Blaine Cook <[e-mail]>                               wrote:
>>> > >>
>>> > >> I know I said I wouldn't, but...
>>> > >>
>>> > >> OpenID and other similar protocols handle the verification of domain
>>> > >> & ownership. Any protocol where authn/authz happen will also do this.
>>> > >>
>>> > >> Isn't it safest if we assume that webfinger is for "untrusted"
>>> > >> discovery (like DNS, which still works, thankyouverymuch) and actions
>>> > >> that need more security / authentication should define that
>>> > themselves?
>>> > >>
>>> > >> b.
>>> > >>
>>> > >> On Nov 29, 2012 9:56 AM, "Breno de Medeiros" <[e-mail]> wrote:
>>> > >>>
>>> > >>> On Thu, Nov 29, 2012 at 4:49 AM, Evan Prodromou <[e-mail]>
>>> > wrote:
>>> > >>>> -1
>>> > >>>>
>>> > >>>> It's the wrong layer. Defining library interfaces seems out of
>>> > scope.
>>> > >>>
>>> > >>> I don't disagree. But the conclusion from a security perspective
>>> > >>> doesn't change. One shouldn't use WF for security applications such
>>> > >>> as authorization with the currently proposed spec formulation.
>>> > >>>
>>> > >>>>
>>> > >>>> I suggest sticking this in security considerations.
>>> > >>>>
>>> > >>>>
>>> > >>>>
>>> > >>>>
>>> > >>>>
>>> > >>>> Breno de Medeiros <[e-mail]> wrote:
>>> > >>>>
>>> > >>>> TLS downgrade attacks means that you always run a server                               over HTTP
>>> > >>>> even when you don't provided that the client will fall back to HTTP
>>> > >>>> when HTTPS port is unavailable. The only difference is that the
>>> > >>>> attacker is doing the HTTP hosting instead.
>>> > >>>>
>>> > >>>> If the library for WF is compliant then it will accept downgrade
>>> > >>>> attacks for interoperability. Unless the spec mandates that
>>> > >>>> compliant client implementations must support configurable option
>>> > >>>> to indicate if only HTTPS is allowed (technically the inputs for WF
>>> > >>>> would be an email address and some security flag with a default
>>> > >>>> value that SHOULD be modifiable) we can't expect that compliant  WF
>>> > >>>> clients will expose this configuration. And if not we can't use WF
>>> > >>>> as a building block for authentication protocols. It is just a
>>> > >>>> violation of layering if OpenIDConnect will invoke the WF client
>>> > >>>> and then try to second guess what the HTTP client that was wrapped
>>> > >>>> within the WF client did during discovery.
>>> > >>>>
>>> > >>>> On Nov 28, 2012 9:44 PM, "Paul E. Jones" <[e-mail]>
>>> > wrote:
>>> > >>>>>
>>> > >>>>> One does not need to run the server on both the HTTPS and HTTP
>>> > port.
>>> > >>>>> If
>>> > >>>>> your domain supports HTTPS, run it only on HTTPS.  Clients MUST
>>> > >>>>> query there first.
>>> > >>>>>
>>> > >>>>>
>>> > >>>>>
>>> > >>>>> Paul
>>> > >>>>>
>>> > >>>>>
>>> > >>>>>
>>> > >>>>> From: [e-mail]
>>> > >>>>> [mailto:[e-mail]]
>>> > >>>>> On Behalf Of Brad Fitzpatrick
>>> > >>>>> Sent: Wednesday, November 28, 2012 12:28 AM
>>> > >>>>> To: [e-mail]
>>> > >>>>> Cc: [e-mail]
>>> > >>>>> Subject: Re: [apps-discuss] Webfinger goals doc
>>> > >>>>>
>>> > >>>>>
>>> > >>>>>
>>> > >>>>> I'm +1 on HTTPS-only too.  I plan to run my own webfinger server,
>>> > >>>>> too, and I recognize it'll be more pain since my personal domain
>>> > >>>>> doesn't have certs or an https server running already, but I'm
>>> > >>>>> fine with some inconvenience in exchange for security and simpler
>>> > >>>>> clients.
>>> > >>>>>
>>> > >>>>>
>>> > >>>>>
>>> > >>>>>
>>> > >>>>>
>>> > >>>>> On Tue, Nov 27, 2012 at 9:18 PM, Mike Jones
>>> > >>>>> <[e-mail]>
>>> > >>>>> wrote:
>>> > >>>>>
>>> > >>>>> +1
>>> > >>>>>
>>> > >>>>>
>>> > >>>>>
>>> > >>>>> From: [e-mail]
>>> > >>>>> [mailto:[e-mail]]
>>> > >>>>> On Behalf Of Dick Hardt
>>> > >>>>> Sent: Tuesday, November 27, 2012 9:04 PM
>>> > >>>>> To: [e-mail]
>>> > >>>>> Cc: [e-mail]
>>> > >>>>> Subject: Re: [apps-discuss] Webfinger goals doc
>>> > >>>>>
>>> > >>>>>
>>> > >>>>>
>>> > >>>>> Let's be brave and say HTTPS-only.
>>> > >>>>>
>>> > >>>>>
>>> > >>>>>
>>> > >>>>> Requiring HTTPS enabled OAuth 2.0 to be MUCH simpler than                               OAuth
>>> > >>>>> 1.0 (yes, a little apples and oranges comparison, but there was a
>>> > >>>>> similar requirement conversation that had the same goal of pushing
>>> > >>>>> complexity to the server from the client -- it also simplifies the
>>> > >>>>> security model)
>>> > >>>>>
>>> > >>>>>
>>> > >>>>>
>>> > >>>>> -- Dick
>>> > >>>>>
>>> > >>>>>
>>> > >>>>>
>>> > >>>>> On Nov 27, 2012, at 6:17 PM, Brad Fitzpatrick
>>> > >>>>> <[e-mail]>
>>> > >>>>> wrote:
>>> > >>>>>
>>> > >>>>>
>>> > >>>>>
>>> > >>>>> I just had a chat with Blaine after his recent "I'm out!" email.
>>> > >>>>> I don't think he's actually out--- he's been working on WebFinger
>>> > >>>>> for as long as I have and cares a lot about it.  I think he was
>>> > >>>>> just grumpy about the process, speed, and confused about goals and
>>> > >>>>> decisions.
>>> > >>>>>
>>> > >>>>>
>>> > >>>>>
>>> > >>>>> Anyway, we had a very productive conversation on chat and                               wrote a
>>> > >>>>> doc together to clarify thought processes and decisions:
>>> > >>>>>
>>> > >>>>>
>>> > >>>>>
>>> > >>>>>
>>> > >>>>>
>>> > >>>>> https://docs.google.com/document/d/1Yr00Tr5d71-E6x7VDtmEaC48SendGW
>>> > >>>>> Qe7XcY99pjQWs/edit#
>>> > >>>>>
>>> > >>>>>
>>> > >>>>>
>>> > >>>>> The doc is open for comments.  I'll try to keep the doc edited and
>>> > >>>>> neutral.  It outlines requirements (aka goals for webfinger),
>>> > >>>>> assumptions, and decisions with pros & cons for each                               and what
>>> > >>>>> decision was ultimately made and why.
>>> > >>>>>
>>> > >>>>>
>>> > >>>>>
>>> > >>>>> The decisions are I'm sure subject to change, but hopefully not
>>> > >>>>> too much.
>>> > >>>>>
>>> > >>>>>
>>> > >>>>>
>>> > >>>>> Let me know what I missed.
>>> > >>>>>
>>> > >>>>>
>>> > >>>>>
>>> > >>>>> My apologies if you don't like the document's medium or fluidity,
>>> > >>>>> but it's the tool I have to work with, and better than nothing.
>>> > >>>>> If you object to the fluidity and want something concrete to reply
>>> > >>>>> to in email, I've snapshotted the document to http://goo.gl/fTMC1
>>> > >>>>> but I won't accept comments or make changes there.  Use whatever
>>> > >>>>> mechanism you prefer.
>>> > >>>>>
>>> > >>>>>
>>> > >>>>>
>>> > >>>>> - Brad
>>> > >>>>>
>>> > >>>>>
>>> > >>>>>
>>> > >>>>>
>>> > >>>>>
>>> > >>>>> Copy of doc for posterity:
>>> > >>>>>
>>> > >>>>>
>>> > >>>>>
>>> > >>>>> WebFinger Goals, Assumptions, and Decisions (SNAPSHOT1)
>>> > >>>>>
>>> > >>>>> aka background reading on understanding the WebFinger spec
>>> > >>>>>
>>> > >>>>> Requirements
>>> > >>>>>
>>> > >>>>>
>>> > >>>>>
>>> > >>>>> given just a string that looks like "[e-mail]", find a
>>> > >>>>> machine-readable metadata document.
>>> > >>>>>
>>> > >>>>> background: since the death of the "finger" protocol (from which
>>> > >>>>> webfinger
>>> > >>>>> gets its name), email-looking identifiers like "[e-mail]"
>>> > have
>>> > >>>>> been
>>> > >>>>> write-only: you can email it (maybe, if it speaks SMTP), but you
>>> > can't
>>> > >>>>> do
>>> > >>>>> any read/discovery operations on it.  You can't find its supported
>>> > or
>>> > >>>>> preferred protocols, its name, its avatar, its public key, its
>>> > >>>>> identity/social/blog server, etc.
>>> > >>>>> the format of the identifier matters because people ("regular
>>> > users")
>>> > >>>>> effortlessly identify with their email addresses, and already use
>>> > them
>>> > >>>>> for
>>> > >>>>> sharing outside (and inside) of social networks
>>> > >>>>>
>>> > >>>>> corollary: WebFinger is not about doing discovery on URLs or URIs
>>> > or
>>> > >>>>> IRIs
>>> > >>>>> or XRIs or any other "dorky" identifier.  Webfinger is about doing
>>> > a
>>> > >>>>> discovery (read) operation on something a non-technical user would
>>> > >>>>> write on
>>> > >>>>> a napkin or give you on a business card.
>>> > >>>>>
>>> > >>>>> clients can be implemented in browsers in JavaScript
>>> > >>>>>
>>> > >>>>> corollary: CORS shout-out in spec
>>> > >>>>> corollary: no DNS component
>>> > >>>>>
>>> > >>>>> delegation to webfinger-as-a-service by larger providers from
>>> > >>>>> self-hosted
>>> > >>>>> or organisational domains is possible (cf. DNS NS records)
>>> > >>>>> latency of updates must be low (unlike DNS)
>>> > >>>>> no service provider (no company) is special-cased.
>>> > >>>>>
>>> > >>>>> Assumptions
>>> > >>>>>
>>> > >>>>>
>>> > >>>>>
>>> > >>>>> the string "[e-mail]" is NOT necessarily an email address,
>>> > even
>>> > >>>>> though most people today associate it with an email address.
>>> > >>>>>
>>> > >>>>> corollary: the "acct:" URI scheme and draft-ietf-appsawg-acct-uri-
>>> > 01
>>> > >>>>> etc
>>> > >>>>>
>>> > >>>>> complexity in specs leads to few and/or poor implementations and
>>> > >>>>> ultimately hinders adoption
>>> > >>>>>
>>> > >>>>> corollary: value simplicity wherever possible, even if it means
>>> > some
>>> > >>>>> things are harder or not possible for some parties.
>>> > >>>>> i.e. we'd rather have a 3 page spec that makes 90% of people happy
>>> > >>>>> rather
>>> > >>>>> than a 30 page spec that makes 95% of people happy, especially if
>>> > such
>>> > >>>>> a
>>> > >>>>> smaller spec means a much improved chance of adoption.
>>> > >>>>>
>>> > >>>>> obvious, but: optional parts in specs need to be optional for only
>>> > one
>>> > >>>>> party (client or server) and required for the other.
>>> > >>>>>
>>> > >>>>> i.e. there needs to always be an intersection of features in the
>>> > spec
>>> > >>>>> that
>>> > >>>>> both parties support.  e.g. can't have both clients and servers
>>> > decide
>>> > >>>>> to
>>> > >>>>> only speak
>>> > >>>>>
>>> > >>>>> there will be more clients than servers
>>> > >>>>>
>>> > >>>>> corollary: it should be easier to write/run a client than a server
>>> > >>>>>
>>> > >>>>> few users own their own domain name and will run their own
>>> > identity
>>> > >>>>> server
>>> > >>>>>
>>> > >>>>> . and those that do own their own domain name will mostly want to
>>> > >>>>> delegate
>>> > >>>>> management of their webfinger profiles or will know what                               they're
>>> > doing
>>> > >>>>> and
>>> > >>>>> therefore don't need to be catered to.
>>> > >>>>> further assumption: most will be running Wordpress or some such
>>> > >>>>> software
>>> > >>>>> already.
>>> > >>>>> corollary: we don't have to cater to this small audience much..
>>> > they'll
>>> > >>>>> know what they're doing, or their hosting software will.
>>> > >>>>>
>>> > >>>>> should be easy to do both client and server. Ideal solution
>>> > balances
>>> > >>>>> both
>>> > >>>>> (delegation for simpler servers)?
>>> > >>>>> standards MUST be programmer-friendly
>>> > >>>>>
>>> > >>>>> Decisions
>>> > >>>>>
>>> > >>>>>
>>> > >>>>>
>>> > >>>>> HTTP vs DNS
>>> > >>>>>
>>> > >>>>> DNS (SRV, TXT, etc) precludes JavaScript clients (as of 2006-2012),
>>> > so
>>> > >>>>> rejected. HTTP instead.
>>> > >>>>>
>>> > >>>>> JSON vs XML
>>> > >>>>>
>>> > >>>>> Per assumption above, we needed to pick at least one as required.
>>> > We
>>> > >>>>> chose JSON.  If both parties advertise (via HTTP headers) that
>>> > they
>>> > >>>>> prefer
>>> > >>>>> XML, that's fine.  JSON is easier for JavaScript clients, as one
>>> > >>>>> advantage.
>>> > >>>>> It's also simpler to read on the page (per the complexity
>>> > argument).
>>> > >>>>> But
>>> > >>>>> both are small arguments and not worth arguing about.  At the end
>>> > of
>>> > >>>>> the day
>>> > >>>>> a decision had to be made, and it was.
>>> > >>>>>
>>> > >>>>> HTTP-ish (Accept / Link headers, etc) vs well-known path
>>> > >>>>>
>>> > >>>>>
>>> > >>>>>
>>> > >>>>> HTTP-ish is more proper, but viewed as too hard for servers to
>>> > route
>>> > >>>>> (routing on headers, rather than request paths) and more
>>> > importantly
>>> > >>>>> too
>>> > >>>>> hard for clients to send (setting headers).
>>> > >>>>> well-known URLs (like /favicon.ico) are gross, though.
>>> > >>>>> Decision: use a well-known URL.
>>> > >>>>> We defined RFC 5785 first instead, to make using a well-known path
>>> > less
>>> > >>>>> offensive.
>>> > >>>>>
>>> > >>>>> One HTTP request vs two.
>>> > >>>>>
>>> > >>>>> Two requests: clients first fetch /.well-known/host-meta (to find
>>> > where
>>> > >>>>> to
>>> > >>>>> do a webfinger query), then fetch that.
>>> > >>>>>
>>> > >>>>> PRO: the host-meta document can be a static file, which makes
>>> > >>>>> delegation
>>> > >>>>> to other webfinger service providers easier for custom domains.
>>> > >>>>> CON: twice the latency, especially for mobile
>>> > >>>>> CON: extra client complexity
>>> > >>>>>
>>> > >>>>> One request: clients just do a query immediately to
>>> > >>>>> /.well-known/webfinger, without consulting host-meta.
>>> > >>>>>
>>> > >>>>> PRO: half the latency
>>> > >>>>> PRO: less client complexity
>>> > >>>>> CON: service providers may need to reverse-proxy the query to the
>>> > right
>>> > >>>>> backend.
>>> > >>>>> CON: harder for small domain names with static webservers to
>>> > delegate.
>>> > >>>>>
>>> > >>>>> Decision: Just one HTTP requests, because we care more about
>>> > client
>>> > >>>>> simplicity than server simplicity.
>>> > >>>>>
>>> > >>>>>
>>> > >>>>> _______________________________________________
>>> > >>>>> apps-discuss mailing list
>>> > >>>>> [e-mail]
>>> > >>>>> https://www.ietf.org/mailman/listinfo/apps-discuss
>>> > >>>>>
>>> > >>>>> ...
>>> > >>>
>>> > >>>
>>> > >>>
>>> > >>> --
>>> > >>> --Breno
>>> > >>> _______________________________________________
>>> > >>> apps-discuss mailing list
>>> > >>> [e-mail]
>>> > >>> https://www.ietf.org/mailman/listinfo/apps-discuss
>>> > >>
>>> > >> _______________________________________________
>>> > >> apps-discuss mailing list
>>> > >> [e-mail]
>>> > >> https://www.ietf.org/mailman/listinfo/apps-discuss
>>> > >
>>> > >
>>> > >
>>> > > --
>>> > > --Breno
>>> > _______________________________________________
>>> > apps-discuss mailing list
>>> > [e-mail]
>>> > https://www.ietf.org/mailman/listinfo/apps-discuss
>>> 
> 
> 
> -- 
> 
> Regards,
> 
> Kingsley Idehen	      
> Founder & CEO 
> OpenLink Software     
> Company Web: http://www.openlinksw.com
> Personal Weblog: http://www.openlinksw.com/blog/~kidehen
> Twitter/Identi.ca handle: @kidehen
> Google+ Profile: https://plus.google.com/112399767740508618350/about
> LinkedIn Profile: http://www.linkedin.com/in/kidehen
> 
> 
> 
>