Subject: [OAUTH-WG] draft-jones-appsawg-webfinger-04

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 4 May 2012 17:31:46 +0000

The above-named draft has been offered as the recommended path forward in terms of converging on a single document to advance through appsawg.  The conversation I saw this week in that regard has seemed mostly positive.

Please review it, or at least the diff, and indicate your support or objection on [email-masked]<mailto:[email-masked]> to adopting this one as the common path forward. We would like to make a decision about which one to begin advancing in the next week or two.

Have a good weekend!

-MSK, APPSAWG co-chair

---

From: Eran Hammer <[email-masked]>
Date: Fri, 4 May 2012 19:41:23 +0000

I support using this document as the starting point for this work.

EH

From: [email-masked] [mailto:[email-masked]] On Behalf Of Murray S. Kucherawy
Sent: Friday, May 04, 2012 10:32 AM
To: [email-masked]
Cc: [email-masked] WG
Subject: [OAUTH-WG] draft-jones-appsawg-webfinger-04

Have a good weekend!

-MSK, APPSAWG co-chair

---

From: "Gonzalo Salgueiro (gsalguei)" <[email-masked]>
Date: Fri, 4 May 2012 15:49:42 -0400

I support this doc being adopted as starting point for WG discussion.

Regards,

Gonzalo

On May 4, 2012, at 3:03 PM, "Murray S. Kucherawy" <[email-masked]> wrote:

> Please review it, or at least the diff, and indicate your support or objection on [email-masked] to adopting this one as the common path forward. We would like to make a decision about which one to begin advancing in the next week or two.
>  
> Have a good weekend!
>  
> -MSK, APPSAWG co-chair
>  
> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss

---

From: John Bradley <[email-masked]>
Date: Sun, 6 May 2012 23:32:26 -0400

While it has some rough edges that we will need to work on, I think this document can form the basis of a single path forward.

John B.
On 2012-05-04, at 1:31 PM, Murray S. Kucherawy wrote:

> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Goix Laurent Walter <[email-masked]>
Date: Mon, 7 May 2012 11:37:06 +0200

I also support this draft as a way forward for the discussion that I think captures the essence of both philosophies.

If such basis is agreed what are the major pending issues?

Regards
Laurent-walter

Da: [email-masked] [mailto:[email-masked]] Per conto di Gonzalo Salgueiro (gsalguei)
Inviato: venerdì 4 maggio 2012 21.50
A: Murray S. Kucherawy
Cc: [email-masked]; [email-masked]
Oggetto: Re: [apps-discuss] draft-jones-appsawg-webfinger-04

Gonzalo

On May 4, 2012, at 3:03 PM, "Murray S. Kucherawy" <[email-masked]<mailto:[email-masked]>> wrote:
The above-named draft has been offered as the recommended path forward in terms of converging on a single document to advance through appsawg.  The conversation I saw this week in that regard has seemed mostly positive.

Have a good weekend!

-MSK, APPSAWG co-chair

_______________________________________________
apps-discuss mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/apps-discuss
Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.

Rispetta l'ambiente. Non stampare questa mail se non è necessario.

---

From: "Paul E. Jones" <[email-masked]>
Date: Mon, 07 May 2012 09:16:42 -0400

Walter,

I'm not sure what the full set of issues will be, but I only have a 
couple of small edits queued for -05 at present (one being "template" 
should be "href" in the example at the end of 4.2 that you pointed out 
to me privately).  We've already worked through a number of issues to 
get to this point, so there may not be a lot of changes needed.  I'll 
not dismiss the possibility that there are editorial issues, but I hope 
we've resolved most of the technical details.

We probably still need to have the discussion of keeping CORS and what 
additions are needed to the security section.  We've made a few changes 
there already, but I'm not sure if it still fully addresses some of the 
privacy concerns.

Paul

On 5/7/2012 5:37 AM, Goix Laurent Walter wrote:
>
> I also support this draft as a way forward for the discussion that I 
> think captures the essence of both philosophies.
>
> *Da:[email-masked] 
> [mailto:[email-masked]] *Per conto di *Gonzalo 
> Salgueiro (gsalguei)
> *Inviato:* venerdì 4 maggio 2012 21.50
> *A:* Murray S. Kucherawy
> *Cc:* [email-masked]; [email-masked]
> *Oggetto:* Re: [apps-discuss] draft-jones-appsawg-webfinger-04
>
>     The above-named draft has been offered as the recommended path
>     forward in terms of converging on a single document to advance
>     through appsawg.  The conversation I saw this week in that regard
>     has seemed mostly positive.
>
>     Please review it, or at least the diff, and indicate your support
>     or objection on [email-masked]
>     <mailto:[email-masked]> to adopting this one as the common
>     path forward. We would like to make a decision about which one to
>     begin advancing in the next week or two.
>
>     Have a good weekend!
>
>     -MSK, APPSAWG co-chair
>
>     [email-masked] <mailto:[email-masked]>

---

From: Blaine Cook <[email-masked]>
Date: Tue, 8 May 2012 08:40:46 +0200

I disagree that the current spec is a good starting point - the issues I've
raised have been ignored, and the spec is now much more complicated from
both sides of the implementation fence.
On May 7, 2012 3:17 PM, "Paul E. Jones" <[email-masked]> wrote:

>  Walter,
>
> I'm not sure what the full set of issues will be, but I only have a couple
> of small edits queued for -05 at present (one being "template" should be
> "href" in the example at the end of 4.2 that you pointed out to me
> privately).  We've already worked through a number of issues to get to this
> point, so there may not be a lot of changes needed.  I'll not dismiss the
> possibility that there are editorial issues, but I hope we've resolved most
> of the technical details.
>
> think captures the essence of both philosophies. ****
>
> ** **
>
> If such basis is agreed what are the major pending issues?****
>
> ** **
>
> Regards****
>
> Laurent-walter****
>
> ** **
>
> *Da:* [email-masked] [mailto:[email-masked]<[email-masked]>]
> *Per conto di *Gonzalo Salgueiro (gsalguei)
> *Oggetto:* Re: [apps-discuss] draft-jones-appsawg-webfinger-04****
>
> ** **
>
> I support this doc being adopted as starting point for WG discussion.****
>
> Regards,****
>
> ** **
>
> Gonzalo****
>
> ** **
>
>
> On May 4, 2012, at 3:03 PM, "Murray S. Kucherawy" <[email-masked]>
> wrote:****
>
>  The above-named draft has been offered as the recommended path forward
> in terms of converging on a single document to advance through appsawg.
> The conversation I saw this week in that regard has seemed mostly positive.
> ****
>
>  ****
>
> Please review it, or at least the diff, and indicate your support or
> objection on [email-masked] to adopting this one as the common
> path forward. We would like to make a decision about which one to begin
> advancing in the next week or two.****
>
>  ****
>
> Have a good weekend!****
>
>  ****
>
> -MSK, APPSAWG co-chair****
>
>  ****
>

---

From: "Paul E. Jones" <[email-masked]>
Date: Tue, 08 May 2012 04:25:27 -0400

Blaine,

Your issues were not ignored, but I do not think there was consensus one 
way or the other on them.  Your points were:
1) Recommendation to use JSON only
2) A question about what the JSON format would look like
3) Direct vs. indirect queries (i.e., whether to use resource parameter)

I replied to each of these and others commented on parts, too.  My opinions:

1) Given that RFC 6415 already specifies use of XML and is only months 
old, I hesitate to demand that only XML be used.  Further, it's trivial 
for the server to do both.  The client will be able to use whatever it 
prefers.  I can be convinced to drop XML, but I think we should make 
this decision carefully and with everyone in agreement.
2) I suggested we use JRD since it is defined.  Was there any 
disagreement on that?
3) This issue is a point where there was clear division.  The OpenID 
Connect team wants to be able to issue a single query and get a reply.  
You had an interest to use a static server.  I investigated how we could 
do both.  If one used Apache, for example, one could build a static site 
and still support the resource URI.  Here's a couple of ways to do it: 
http://www.packetizer.com/webfinger/server.html (using either .htaccess 
or the global config file).  What cannot be accomodated is the "rel" 
parameter, but I'd guess static sites will not produce voluminous 
results, anyway.

So, it's not accurate to say your issues were ignored.  We simply did 
not have strong consensus one way or the other.  There were strong 
opinions on (3), so I tried to find a solution that might be 
acceptable.  We may need more discussion on all of these points, of course.

Paul

On 5/8/2012 2:40 AM, Blaine Cook wrote:
>
> I disagree that the current spec is a good starting point - the issues 
> I've raised have been ignored, and the spec is now much more 
> complicated from both sides of the implementation fence.
>
> On May 7, 2012 3:17 PM, "Paul E. Jones" <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Walter,
>
>     I'm not sure what the full set of issues will be, but I only have
>     a couple of small edits queued for -05 at present (one being
>     "template" should be "href" in the example at the end of 4.2 that
>     you pointed out to me privately).  We've already worked through a
>     number of issues to get to this point, so there may not be a lot
>     of changes needed.  I'll not dismiss the possibility that there
>     are editorial issues, but I hope we've resolved most of the
>     technical details.
>
>     We probably still need to have the discussion of keeping CORS and
>     what additions are needed to the security section.  We've made a
>     few changes there already, but I'm not sure if it still fully
>     addresses some of the privacy concerns.
>
>     Paul
>
>>     I also support this draft as a way forward for the discussion
>>     that I think captures the essence of both philosophies.
>>
>>     <mailto:[email-masked]>
>>     *Cc:* [email-masked] <mailto:[email-masked]>;
>>     On May 4, 2012, at 3:03 PM, "Murray S. Kucherawy"
>>     <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>         The above-named draft has been offered as the recommended
>>         path forward in terms of converging on a single document to
>>         advance through appsawg.  The conversation I saw this week in
>>         that regard has seemed mostly positive.
>>
>>         Please review it, or at least the diff, and indicate your
>>         support or objection on [email-masked]
>>         <mailto:[email-masked]> to adopting this one as the
>>         common path forward. We would like to make a decision about
>>         which one to begin advancing in the next week or two.
>>
>>         Have a good weekend!
>>
>>         -MSK, APPSAWG co-chair
>>
>     [email-masked] <mailto:[email-masked]>

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 8 May 2012 17:55:00 +0300

Hi Murray, 

it is great to see that you are pushing things forward here but I believe you are going a bit too fast. 

From the comments I have seen so far I got the impression that many got confused by UR schemes: mailto: and the acct: are different. 
The discussions around XML vs. JSON are unfortunately also hiding the real important discussion, namely privacy. 

We are actually building, without further thinking about it, a mechanism that offers worse privacy properties compared to what we have in other protocols today.

See this in terms of the interaction between a relying party and an identity provider then other IETF protocols today (e.g., AAA) does not require the relying party to see the username part of the identifier. In fact AAA offers various mechanisms to hide the username component to the relying party since it is really only needed by the identity provider.

So, I would encourage the group to think about how to accomplish equivalent functionality without unnecessarily revealing identifiers to parties that are not supposed to get them.

I also think it is useful to think about the bigger picture,namely the integration with other protocols (such as OAuth). This will in most cases be needed when you actually fetch the data that is behind the discovered URIs. Assuming that all information is public anyway is not realistic and protocol design has to work with the difficult assumptions (not with the simplest). Furthermore, the usage of CORS is completely confused in the document. 

Hence, I heavily object to use this document as a starting point. 

I may also be the case that WebFinger is not the right tool for something like OAuth (and for discovery of protected resources altogether) since we do not want to design a solution that on one hand allows us not to reveal any user identifiers to the relying party (the client in OAuth) based on the current design and then completely destroy these properties when we add the discovery mechanisms in front of it. 

Ciao
Hannes

PS: I met some W3C folks last week and they mentioned that we should also take a look at Web Intents. I have not done that yet and do not know how suitable the W3C developed mechanisms therefore is.

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 8 May 2012 17:55:50 +0300

Gonzalo: it is great that you, as a co-author, support your own document but I don't think it is particular helpful.

---

From: Blaine Cook <[email-masked]>
Date: Tue, 8 May 2012 17:30:52 +0200

> So, I would encourage the group to think about how to accomplish equivalent functionality without unnecessarily revealing identifiers to parties that are not supposed to get them.

Webfinger isn't about authentication. It is *explicitly* about
discovering information about an entity (usually a person) when you
(the relying party) *already have* their identifier.

Again: There is NO privacy leak in exposing the identifier to the RP,
because they already know it.

Again: There is NO privacy leak in exposing the identifier to the SP,
because they control it.

Even in the context of authentication, I'm surprised you're saying
this because I've repeatedly claimed that the *major failing* with
OpenID *.* is that the relying party isn't given knowledge of *who* is
trying to authenticate in the first place. It's a cryptographic
property that looks lovely on paper, but is a damaging folly when
translated to something that end users are expected to interact with.

> I also think it is useful to think about the bigger picture,namely the integration with other protocols (such as OAuth). This will in most cases be needed when you actually fetch the data that is behind the discovered URIs. Assuming that all information is public anyway is not realistic and protocol design has to work with the difficult assumptions (not with the simplest).

Agreed, the actual information conveyed by Webfinger will normally be
private. *However*, as discussed on this list, on the OAuth list, and
in many other places, the mechanism(s) for authentication and
authorisation to access the relevant Webfinger profiles is best dealt
with by allowing any valid HTTP mechanisms.

Specific protocols that rely upon webfinger should define their own
authentication requirements, where sensible.

> Hence, I heavily object to use this document as a starting point.

I have many concerns with this document, too, as mentioned earlier.

> I may also be the case that WebFinger is not the right tool for something like OAuth (and for discovery of protected resources altogether) since we do not want to design a solution that on one hand…

No-one is forcing all OAuth services to rely upon webfinger discovery.
OpenID Connect needs something like this, because users (and their RPs
in turn) need to know their identifier in order to be able to sign in.
Some RPs that interact with OAuth-enabled services (e.g., cloud
document services) will benefit from webfinger. Others won't,
especially where the RP shouldn't or can't know who the user is, but
should have access to a service.

FWIW, I think you're blowing the privacy concerns way out of
proportion, especially in the context of a world where many actively
hostile actors can identify users by analysing router traffic that
they obtain from back-doors in switches manufactured by Ericsson. ;-)

b.

---

From: Gonzalo Salgueiro <[email-masked]>
Date: Tue, 8 May 2012 14:52:31 -0400

Hannes: While I'm clearly honored by your interest in me and my activities, it is not my intent to artificially pump up a document on which I am a co-author.  Everyone on this list knows I am an author on it as we have discussed it exhaustively for the past month and a half. I was merely indicating my support of the compromised direction being proposed (as we were at a bit of an impasse with two documents in call for adoption that were proposing a solution for the same problem space). It took a good bit of on-list and off-list discussion for the SWD and WF camps to draw a line in the sand and come to an agreement on a compromise that was a mutually satisfying starting point that the WG could get behind. This proposal was put forth (and supported) separately by Mike Jones (a co-author on SWD) and Paul Jones (a co-author on WF). I, as another co-author of WF, was voicing my support of the compromise as a starting point. I don't believe any of the co-authors involved were at fault or acted with irregularity.

Cheers,

Gonzalo