Subject: [apps-discuss] 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: Peter Saint-Andre <[email-masked]>
Date: Fri, 04 May 2012 13:51:27 -0600

On 5/4/12 11:31 AM, Murray S. Kucherawy 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.

I think this is a good starting point.

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/

---

From: Likepeng <[email-masked]>
Date: Mon, 7 May 2012 00:38:35 +0000

> I think this is a good starting point.

+1.

Kind Regards
Kepeng
-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]] 代表 Peter Saint-Andre
发送时间: 2012年5月5日 3:51
收件人: Murray S. Kucherawy
抄送: [email-masked]
主题: Re: [apps-discuss] draft-jones-appsawg-webfinger-04

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/

---

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
>
>     [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: Eran Hammer <[email-masked]>
Date: Tue, 8 May 2012 06:50:51 +0000

All the issues raised should be the starting point for discussion on this as a WG item. I do not think any of them has been resolved. The only point here is that we have a single document for a starting point. Using this document does not reflect any consensus on the final product. Your three items should be listed in the issue tracker as soon as this has progressed enough.

EH

From: [email-masked] [mailto:[email-masked]] On Behalf Of Blaine Cook
Sent: Monday, May 07, 2012 11:41 PM
To: Paul E. Jones
Cc: [email-masked]; [email-masked]
Subject: Re: [apps-discuss] [OAUTH-WG] R: draft-jones-appsawg-webfinger-04

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

Regards
Laurent-walter

Da: [email-masked]<mailto:[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]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Oggetto: Re: [apps-discuss] draft-jones-appsawg-webfinger-04

Gonzalo

Have a good weekend!

-MSK, APPSAWG co-chair

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

---

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.
>
>     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: Eran Hammer <[email-masked]>
Date: Tue, 8 May 2012 15:03:51 +0000

Neither was this comment.

EH

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Hannes Tschofenig
> Sent: Tuesday, May 08, 2012 7:56 AM
> To: Gonzalo Salgueiro
> Subject: Re: [OAUTH-WG] [apps-discuss] draft-jones-appsawg-webfinger-04
> 
> <[email-masked]> wrote:
> >
> 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: Blaine Cook <[email-masked]>
Date: Tue, 8 May 2012 17:16:36 +0200

I just meant that my comments aren't reflected in the document, not
that they were ignored completely. I'm not sure what the difference is
between this process and the one that comes next, but I trust that
various concerns will be addressed.

b.

On 8 May 2012 10:25, Paul E. Jones <[email-masked]> wrote:
>  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) 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
>
>
>> 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)
>> 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.
>>
>>
>>
>> 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: Hannes Tschofenig <[email-masked]>
Date: Tue, 8 May 2012 18:23:06 +0300

So, you think it is a good practice if the authors + their co-workers indicate support for their own documents?

---

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: Peter Saint-Andre <[email-masked]>
Date: Tue, 08 May 2012 09:31:38 -0600

Hi Blaine,

The question is: "do we think that draft-jones-appsawg-webfinger-04 will
provide a good starting point for a solution to this problem?" I too
have feedback and concerns that I shall raise if this working group
decides that this Internet-Draft is a good starting point.

Peter

---

From: Eran Hammer <[email-masked]>
Date: Tue, 8 May 2012 15:37:19 +0000

I think it is perfectly fair, and common practice.

You make it sound like it's some sort of competition or process manipulation. Everyone here has bias. I don't recall you raising an issue on the OAuth list every time a certain Microsoft employee affirmed support for his co-worker documents and positions (in fact those two have *never* "voted" differently).

This criticism seems to be reserved for cases where *you* disagree with the outcome. 

EH

> From: Hannes Tschofenig [mailto:[email-masked]]
> Sent: Tuesday, May 08, 2012 8:23 AM
> To: Eran Hammer
> Cc: Hannes Tschofenig; Gonzalo Salgueiro; [email-masked]
> >> From: [email-masked] [mailto:[email-masked]] On
> >> Behalf Of Hannes Tschofenig
> >> Gonzalo: it is great that you, as a co-author, support your own
> >> document but I don't think it is particular helpful.
> >>
> >> through appsawg.  The conversation I saw this week in that regard has
> >> seemed mostly positive.
> >>>>
> >>>> or objection
> >> 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: John Bradley <[email-masked]>
Date: Tue, 8 May 2012 11:47:35 -0400

Hannes,

Deep breath.

The question is not if the document is perfect, only if it can be the starting point.

I suspect you are mixing up authentication in your comments.

SWD and WF provide information about identifiers.   

It is true that WF can also provide alias information that can be used to correlate, though that is sort of the point of publicly listing them.

We have agreed that WF can optionally be a protected resource to allow selective disclosure at providers that want to support that.

The goal was to not prevent some sites that only want to serve public information from doing so.

I too have concerns about defining a new URI scheme and the likelihood of getting that approved.

However we need someplace to start. 

Are you advocating using SWD as the starting document, or more specific changes to WF?

John B.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 8 May 2012 16:24:31 +0000

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Hannes Tschofenig
> Cc: [email-masked]
> Subject: Re: [apps-discuss] [OAUTH-WG] draft-jones-appsawg-webfinger-04
> 
> So, you think it is a good practice if the authors + their co-workers
> indicate support for their own documents?

I find the comment harmless, since the people who have to evaluate consensus are quite aware of who the authors are.

-MSK

---

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

---

From: SM <[email-masked]>
Date: Tue, 08 May 2012 12:16:05 -0700

Hi Hannes,
At 08:23 08-05-2012, Hannes Tschofenig wrote:
>So, you think it is a good practice if the authors + their 
>co-workers indicate support for their own documents?

It does not matter in the case of the author it is considered as a 
"no operation performed".  Any other individual, even a co-worker, 
may indicate support for the document.

Regards,
-sm

---

From: Phil Hunt <[email-masked]>
Date: Tue, 8 May 2012 12:34:23 -0700

It took the author's agreement in the larger context of starting with the doc and making the discussed changes.   

Phil

On 2012-05-08, at 12:16, SM <[email-masked]> wrote:

> It does not matter in the case of the author it is considered as a "no operation performed".  Any other individual, even a co-worker, may indicate support for the document.
> 
> Regards,
> -sm

---

From: Melvin Carvalho <[email-masked]>
Date: Sun, 13 May 2012 12:39:33 +0200

> advancing in the next week or two.****

Support for the merge of WF / SWD in general.  Like the look of the new
document.

Only objection may be to keeping in the creation of the new URI scheme
(acct:).

I think SWD has proven that this problem can be solved without introducing
that dependency.

****

---

From: John Bradley <[email-masked]>
Date: Sun, 13 May 2012 20:20:30 -0400

One observation is that because SWD is a service the normalization happens on the server as it knows best what it's local structure is. 

So in SWD of the user types in [email-masked] you send [email-masked] to example.com and let it sort it out.

In WF the premise was to have a simple server supporting static documents.  That requires the client to perform more normalization on what the user inputs, otherwise the server needs to support static documents for all possible normalizations.

People may criticize SWD for making the servers life more complicated, but at the end of the day only the server can know what schemes it supports and if email:  acct: http: and https: schemes have some equivalence.

For WF to continue supporting static files/rewrite rules we probably need the client to normalize email looking things to a singe form.   

Having been around the block with the W3C on XRI and the creation of a new URI scheme.  I can tell people that getting acct: registered or WF through the approval process with it will not be a walk in the park.

Stripping the scheme from an email like identifier is probably the best bet, though that perhaps leaves a problem of what to use as the subject of the response if it must be a URI.

I do understand why acct: solves some problems for WF,  and dropping it may take some reworking.

John B.

On 2012-05-13, at 6:39 AM, Melvin Carvalho wrote:

> Support for the merge of WF / SWD in general.  Like the look of the new document.
> 
> Only objection may be to keeping in the creation of the new URI scheme (acct:). 
> 
> I think SWD has proven that this problem can be solved without introducing that dependency.
> 
> 
>  
> 
> -MSK, APPSAWG co-chair
> 
>  
> 
>

---

From: Michiel de Jong <[email-masked]>
Date: Mon, 14 May 2012 10:29:07 +0200

At the risk of feeding the fire here, on the 'acct:user@host' vs
'user@host' issue, I would like to argue that the fact that acct: is
not a URI scheme has nothing to do with it. It's only a parameter of a
query format, nothing more. IMHO this whole issue is only of academic
interest and does not have any relevance to what the spec can do.

On Mon, May 14, 2012 at 2:20 AM, John Bradley <[email-masked]> wrote:
> In WF the premise was to have a simple server supporting static documents.
>  That requires the client to perform more normalization on what the user
> inputs, otherwise the server needs to support static documents for all
> possible normalizations.

i don't think that's the reason - whether you use 'acct:user@host' or
'user@host' or 'urn:acct:user@host' doesn't make for more or less work
on the client or on the server, i think.

> Stripping the scheme from an email like identifier is probably the best bet,
> though that perhaps leaves a problem of what to use as the subject of the
> response if it must be a URI.

You could use the fact that the document itself is a description-URI
for the user. so subject can be
https://host/.well-known/host-meta?resource=acct:user@host.

> getting acct: registered or WF through the approval process with it will not be a walk in the park.

Why would that be needed? Look at other unregistered schemes like
bitcoin:, chrome-extension:, torrent:, javascript:, git:, ssh:, and
actually finger: itself. The fact that it's not a URI scheme simply
means that a user cannot use the address bar of their browser to go
there, and that links cannot read <a href="acct:user@host">me</a> and
then expect all major browsers to correctly resolve that. IMHO it was
ever a goal to make browsers resolve webfinger straight from the
address bar or from link targets. So there's no problem here.

Those complaining that acct:user@host is not a URI (actually it would
have to be 'urn:acct:' for that, i think) can be told: you are right,
it's not a W3C registered URI scheme. But the information published
here is linkable from the web (using
https://host/.well-known/host-meta?resource=acct:user@host as the
description-URI of the user), and the document itself consists
entirely of a wealth of links to other resources.

I've had long one-on-one discussions about this with Melvin, and still
hope that we can simply just drop this IMHO academic issue. does it
affect how the service works and what it can do? i think not at all.

if some client implementers refuse to add in the 'acct:' because it
looks like a URI, then maybe we can add a requirement on servers that
they should allow that, and simply consider 'user@host' and
'acct:user@host' to mean the same thing (actually, some
implementations already do this - since it is clear that that is what
the client meant, and also since it's an easy mistake to make for
client developers). Maybe that's a way to settle the issue? So the
resource parameter could then be one of four things:

- a description-URI of any type of resource, e.g. http://home.me/fridge
- a contact-URI of a user, for instance mailto:user@host
- acct:user@host to say 'i know it's that user at that host, but i
don't know their URI'
- user@host to be interpreted to mean the same as acct:user@host

On the whole, i think the important next step is to list and settle
only those issues that block the path from
draft-jones-appsawg-webfinger-04 to a common, merged,
draft-jones-simple-web-discovery-03. I think renaming webfinger to
simple web discovery (as Blaine mentioned as an option, and Paul
suggested, and Mike was willing to discuss) would be a good next big
step to focus on.

If the names merge, the specs merge. The good thing is they already
have their 'draft-jones-' prefix in common. ;)

My 2ct,
Michiel

---

From: "Paul E. Jones" <[email-masked]>
Date: Tue, 15 May 2012 14:49:24 -0400

> 'user@host' issue, I would like to argue that the fact that acct: is not a
> URI scheme has nothing to do with it. It's only a parameter of a query
> format, nothing more. IMHO this whole issue is only of academic interest
> and does not have any relevance to what the spec can do.

I disagree.  Keep in mind that WebFinger is about discovering information
about anything.  It might be a person, a device, a web page, or something
else.  The URI scheme is what distinguishes one entity from another.  One
could use mailto: as a URI scheme.  That is perfectly valid and that might
be the choice made by OpenID Connect, though I would not recommend it.

Not all users have an email address.  I hate mentioning twitter so often,
but it is the poster child for a popular service that is not associated with
email addresses.  Nonetheless, one might want to issue a query against an
account at twitter.com.  One might want to use his twitter ID as a means of
logging into sites using OpenID Connect.  I have accounts at lots of web
sites, all of which might serve some information about me via WebFinger.
However, not a one of them are associated with my email address, except my
own server.

It's important to understand that "acct" is not the only URI scheme that can
be used by WebFinger, but I think it is nonetheless important in order to
issue queries against some accounts at various web sites.

We've debated this at length.  It's been at least a couple of years, I
think.  We could use no scheme.  We could use "mailto".  We could use
"acct".  However, not all schemes work for all situations.  If I want to log
in, perhaps I enter [email-masked] and that is translated into
mailto: or acct: and one finds my OpenID server.  Perhaps you learn that I
have a COOL_NEW_WHATEVER account and you want to learn more about the
account.  Well, you can query it using my email address.  Perhaps the
service stores pictures and you want the URL to the picture feed.  That feed
URL would be provided by my account at the COOL_NEW_* service.  Perhaps the
service is a new cloud storage service and you can get access to files I
post to the public.  The URL to my public documents would be published by
the service.  Again, you would not necessarily learn that by querying my
email ID.

This is the web and information is scattered all over the place.  I am not
likely to store everything about me in one place, but I might provide
pointers to other places.  Thus, the WF draft not only introduces the "acct"
URI scheme, but also the "acct" link relation value, too.  I think this is
very powerful, necessary, and not merely an academic exercise.

So, imagine these links that one might discover at using
acct:[email-masked]

<Link rel="acct" href="acct:paulej@cool_new_pic_service"/>
<Link rel="acct" href="acct:10475893@cool_new_cloud_storage_service"/>
<Link rel="acct" href="acct:543543@cool_new_social_network"/>
<Link rel="acct" href="acct:paulej555@cool_new_whatever"/>

This allows me to direct querying entities to other accounts I own.  But,
even without knowing my email address and knowing I am user "paulej" at this
pic service, it should be possible to query that account for whatever
information I am sharing there.  It's not a "mailto" URI and we should not
use "mailto:paulej@cool_new_pic_service".  We could debate that at length,
but we've already debated it.  Use of "mailto" in that case is just wrong. 

Paul

---

From: John Bradley <[email-masked]>
Date: Tue, 15 May 2012 18:15:05 -0400

Hi Paul,

I wasn't recommending changing to email: 

I do appreciate the predicament.  I have been in the same place with xri. 

The sensible thing is to have a registered acct: URI scheme so that identifiers can be normalized to it and perhaps more importantly it can be used for link relations.

However I think we need to get some sort of determination on if the spec will get approved by the ISEG if it requires the registration of a new scheme.

SWD side-stepped the issue by not having the client normalize the input.  

You find the host in the input and send exactly that string as the parameter in your get to the .well-known location on that host.  
The server did all the work.

In to have WF work the client will need to continue to do some normalization or many servers using static configs are going to be much less useful.

My immediate problem is what to normalize [email-masked] to before sending it as the value of the resource parameter.

I don't want to go down a path and then have W3C or IANA tell ISEG to send the spec back due to violating the no new schemes agreement.

Is this something a chair can clarify for us.    

I think it is critical to resolve this question to reduce the risk of merging SWD with WF.

John B.

---

From: Blaine Cook <[email-masked]>
Date: Tue, 15 May 2012 23:57:02 +0100

I think this is probably a moot point; webfinger doesn't require that the
client normalize the identifier into an acct URI, and if it does (a) it's a
recent addition, and (b) I for one would be opposed to that requirement
(even though in an ideal world even DNS lookups would have a URI scheme
specified).

b.
 On May 15, 2012 11:15 PM, "John Bradley" <[email-masked]> wrote:

> The sensible thing is to have a registered acct: URI scheme so that
> identifiers can be normalized to it and perhaps more importantly it can be
> used for link relations.
>
> However I think we need to get some sort of determination on if the spec
> will get approved by the ISEG if it requires the registration of a new
> scheme.
>
> You find the host in the input and send exactly that string as the
> parameter in your get to the .well-known location on that host.
> In to have WF work the client will need to continue to do some
> normalization or many servers using static configs are going to be much
> less useful.
>
> My immediate problem is what to normalize [email-masked] to before sending
> it as the value of the resource parameter.
>
> I don't want to go down a path and then have W3C or IANA tell ISEG to send
> the spec back due to violating the no new schemes agreement.
>

---

From: Bob Wyman <[email-masked]>
Date: Tue, 15 May 2012 19:01:47 -0400

+1. WebFinger should permit any URI to be used -- including an acct: URI.

On Tue, May 15, 2012 at 6:57 PM, Blaine Cook <[email-masked]> wrote:

>> I don't want to go down a path and then have W3C or IANA tell ISEG to
>> send the spec back due to violating the no new schemes agreement.
>>

---

From: "Paul E. Jones" <[email-masked]>
Date: Tue, 15 May 2012 19:02:28 -0400

John,

Agreed -- it would be good if the chairs could find out whether acct would
get rejected on the grounds that somebody somewhere decided there shall be
no new URI schemes.

And who decided this "no new schemes"?  HTTP is all we'll ever need?  This
restriction seems strange.  I appreciate the scrutiny, but find it odd one
would just declare a freze.

Paul

> From: [email-masked] [mailto:[email-masked]]
> On Behalf Of John Bradley
> Sent: Tuesday, May 15, 2012 6:15 PM
> To: Michiel de Jong
> >>  That requires the client to perform more normalization on what the
> >> user inputs, otherwise the server needs to support static documents
> >> for all possible normalizations.
> >
> >> Stripping the scheme from an email like identifier is probably the
> >> best bet, though that perhaps leaves a problem of what to use as the
> >> subject of the response if it must be a URI.
> >

---

From: "Paul E. Jones" <[email-masked]>
Date: Tue, 15 May 2012 19:04:50 -0400

Blaine,

The WF spec has no normalization requirement.  I think John’s recommendation comes partly from your desire to ensure that static sites work.  Having a user account specified using a single URI scheme (vs. multiple) makes it easier to create static sites.

To be clear, though, any URI is valid with WebFinger.

Paul

From: [email-masked] [mailto:[email-masked]] On Behalf Of Blaine Cook
Sent: Tuesday, May 15, 2012 6:57 PM
To: John Bradley
Cc: [email-masked]
Subject: Re: [apps-discuss] [OAUTH-WG] draft-jones-appsawg-webfinger-04

I think this is probably a moot point; webfinger doesn't require that the client normalize the identifier into an acct URI, and if it does (a) it's a recent addition, and (b) I for one would be opposed to that requirement (even though in an ideal world even DNS lookups would have a URI scheme specified).

b.

Hi Paul,

John B.

---

From: John Bradley <[email-masked]>
Date: Tue, 15 May 2012 19:29:52 -0400

Yes my concern is that SWD didn't need normalization on the client.

While WF dosen't require it static templates won't work dependably, if the site only support's files with acct: then queries without it won't work and vica versa.

If we are going to support those static type server configs they should at least work reliably, and that requires some sort of normalization on the client end.

John B.

---

From: Blaine Cook <[email-masked]>
Date: Wed, 16 May 2012 00:49:54 +0100

On 16 May 2012 00:29, John Bradley <[email-masked]> wrote:
> While WF dosen't require it static templates won't work dependably, if the
> site only support's files with acct: then queries without it won't work and
> vica versa.
>
> If we are going to support those static type server configs they should at
> least work reliably, and that requires some sort of normalization on the
> client end.

I'm really not sure how you came to this conclusion? Static host-meta
files with URI templates work perfectly well to discover the actual
profile server. The template variable name is "uri", but the spec says
(or should say, if there's any confusion) that "uri" can be a "bare"
email address or any URI.

The only thing that I can guess is that it might be tricky in an
environment where you're hosting static profile documents for each
address? I don't think webfinger mandates or even recommends that –
the only static component is host-meta, to enable sites that can't /
don't want to host a dynamic profile server to refer clients to a
location that does host a dynamic server.

b.

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 15 May 2012 18:08:02 -0600

> would just declare a freze.

There is no such freeze. New URI schemes get approved regularly. The
most recent ones are 'ws' and 'wss' for WebSocket (RFC 6455), and 'xcon'
and 'xcon-userid' for centralized conferencing (RFC 6501).

http://www.iana.org/assignments/uri-schemes.html

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: John Bradley <[email-masked]>
Date: Tue, 15 May 2012 20:24:16 -0400

My understanding is that the W3C and IANA have a "Very high bar that must be be met before a new URI scheme is granted."   

That is code for http URI are names and can be used to name anything including abstract objects and concepts (Think RDF),  the granting of any new URI schemes fragments the namespace and is bad for the internet.

Some people like Tim Berners-Lee have quite strong views on this.

This document from the W3C sets out part of their position http://www.w3.org/2001/tag/doc/SchemeProtocols.html

Mark Nottinham, Dave Orchard and others will likely remember the fight over creating a new scheme for xri as an abstract identifier almost exactly like WF is proposing for acct:

I hope things have changed, I was on the pro new scheme side at the time, and am still a bit sensitive about having been vilified over it.

Who know it key have just been personal, but we should be sure the IETF will push it forward.

John B.

---

From: John Bradley <[email-masked]>
Date: Tue, 15 May 2012 20:57:19 -0400

OK I think where the confusion comes from was the the original WF notion that the host-meta template translates to static files in the directory.

If we are all good on the notion that host-meta needs to point a service like SWD that can deal with un-normalized input like [email-masked]' then I then I think we are good.

Part of what may have confused me was the examples of using rewrite rules to retrieve static XRD files.

John B.

---

From: Melvin Carvalho <[email-masked]>
Date: Wed, 16 May 2012 09:09:21 +0200

On 16 May 2012 02:24, John Bradley <[email-masked]> wrote:

> My understanding is that the W3C and IANA have a "Very high bar that must
> be be met before a new URI scheme is granted."
>

I do believe there is a high bar, yes.  In some ways it's a double edged
sword.

For example, I'm working with the bitcoin community to try and get bitcoin:
registered, but it's a fair amount of paperwork to go through, and you're
never sure if it's going to make it to official status.

However, it's probably a good thing that there is some oversight.  I think
one question that may reasonably be asked is 'Can this problem be solved
without creating a new URI scheme?'. I think if we take the best parts from
SWD and the best parts from WF, the answer would be yes, and also, lead to
a shorter, and more easily implemented spec.

Does anyone have a pointer to the "normalization" process, I could be
mistaken, but I was unable to find that term referenced in the spec.

>
> That is code for http URI are names and can be used to name anything
> including abstract objects and concepts (Think RDF),  the granting of any
> new URI schemes fragments the namespace and is bad for the internet.
>
> This document from the W3C sets out part of their position
> http://www.w3.org/2001/tag/doc/SchemeProtocols.html
>
> Mark Nottinham, Dave Orchard and others will likely remember the fight
> over creating a new scheme for xri as an abstract identifier almost exactly
> like WF is proposing for acct:
>
> I hope things have changed, I was on the pro new scheme side at the time,
> and am still a bit sensitive about having been vilified over it.
>
> send

---

From: Goix Laurent Walter <[email-masked]>
Date: Wed, 16 May 2012 12:43:49 +0200

Hi all,

I do support the restriction of resources to be URIs. Normalization at server side may be easier from a programmatic point of view (arguable) but it may also lead to interop issues if not clearly defined, as each server may normalize differently and thus provide a different output or throw an error.
The entire standard community has been pushing over years for using URIs in general as identifiers instead of pure tokens or random strings to keep consistent and ensure at least a basic foundation for interoperability, with very few limitations (a scheme and a token basically). The scheme is what actually guarantees interop and understanding of the whole id, but I think we all know that.
As Blaine and Paul mentioned the current spec already allows "anyURI", so you can use it with http, mailto, urn... and acct. it may not be meaningful for swd use case but then one could argue that it wouldn't neither be very hard in openid to request adding "acct:" as a prefix (even if not meaningful in that case but treated as pure string) in case the id is not a uri. I do guess it would accommodate "both" use cases (wf & swd) and more to come in the future... Is it that problematic or illogic to add a string prefix to accommodate/match the syntax of a "standard" protocol (relying on uris and not any string as identifier...) ?

walter

> -----Messaggio originale-----
> Da: [email-masked] [mailto:apps-discuss-
> [email-masked]] Per conto di John Bradley
> Inviato: mercoledì 16 maggio 2012 2.57
> A: Blaine Cook
> Oggetto: Re: [apps-discuss] [OAUTH-WG] draft-jones-appsawg-webfinger-04
>
> OK I think where the confusion comes from was the the original WF
> notion that the host-meta template translates to static files in the
> directory.
>
> If we are all good on the notion that host-meta needs to point a
> service like SWD that can deal with un-normalized input like
> [email-masked]' then I then I think we are good.
>
> >> While WF dosen't require it static templates won't work dependably,
> >> if the site only support's files with acct: then queries without it
> >> won't work and vica versa.
> >>
> >> If we are going to support those static type server configs they
> >> should at least work reliably, and that requires some sort of
> >> normalization on the client end.
> >
> > address? I don't think webfinger mandates or even recommends that -

---

From: Goix Laurent Walter <[email-masked]>
Date: Wed, 16 May 2012 12:57:35 +0200

One can discuss whether or not the « acct : » scheme needs to be part of the wf spec or not.

Anyway I do believe this is truly needed to be registered, for the use case raised by Paul (many popular SN websites do not offer email services and an SN id do not match the email address, and there are more to come probably so Social Network identifiers do deserve their dignity per se), but also to be able to use this identifier as a true URI in various specifications nowadays requiring URI/IRIs as identifiers. I am talking about ActivityStreams (both json and atom representations), Salmon, PubSubHubbub and OpenSocial (as Global identifiers in the path of REST calls) for example, all related to the Social Network world.  They all need user identifiers in the form of a URI and unless using http: for everything there is a clear need for user identifiers that people remember, such as user@domain they've been used to use for years now.
It is also a matter of integration with other services: sip, xmpp (and mailto) share this same syntax for identifying users, and service providers who want to integrate services and identities can more easily provide accounts with a unique user@domain identity that can work over a variety of protocols, each associated in general to a dedicated scheme (hidden to the end user)

Isn't this enough to justify the need for formalizing a new scheme that already could identify more than 1Bn of active users worldwide?
walter

Da: [email-masked] [mailto:[email-masked]] Per conto di Melvin Carvalho
Inviato: mercoledì 16 maggio 2012 9.09
A: John Bradley
Cc: Mark Nottingham; [email-masked]
Oggetto: Re: [apps-discuss] [OAUTH-WG] draft-jones-appsawg-webfinger-04

On 16 May 2012 02:24, John Bradley <[email-masked]<mailto:[email-masked]>> wrote:
My understanding is that the W3C and IANA have a "Very high bar that must be be met before a new URI scheme is granted."

I do believe there is a high bar, yes.  In some ways it's a double edged sword.

For example, I'm working with the bitcoin community to try and get bitcoin: registered, but it's a fair amount of paperwork to go through, and you're never sure if it's going to make it to official status.

However, it's probably a good thing that there is some oversight.  I think one question that may reasonably be asked is 'Can this problem be solved without creating a new URI scheme?'. I think if we take the best parts from SWD and the best parts from WF, the answer would be yes, and also, lead to a shorter, and more easily implemented spec.

Does anyone have a pointer to the "normalization" process, I could be mistaken, but I was unable to find that term referenced in the spec.

John B.

On 2012-05-15, at 7:02 PM, Paul E. Jones wrote:

>> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>]
>> Cc: [email-masked]<mailto:[email-masked]>
>> My immediate problem is what to normalize [email-masked]<mailto:[email-masked]> to before sending
>>> On Mon, May 14, 2012 at 2:20 AM, John Bradley <[email-masked]<mailto:[email-masked]>> wrote:
>>> - a contact-URI of a user, for instance mailto:user@host<mailto:user@host>

---

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 16 May 2012 09:22:58 -0400

John, Blaine,

I do not believe there is any room on the host-meta spec (RFC 6415) for
"bare" email addresses.  Host-meta (and thus WebFinger) operates on a URI
and a URI (per RFC 3986) must always have a "scheme".  An email address
without a scheme associated with it is just a string.

On my own server, I do look for bare email addresses and prepend "acct" to
them.  It's functional, but why do that on the server versus the client?  I
implemented that since Blaine suggested it a few years ago, but it also
follows the practice of being strict in what you send and tolerant in what
you receive.   Clients should do the same.  Clients should send a
well-formed URI.

Why not just bare email addresses?  WebFinger operates on URIs.  All kinds
of URIs can be passed to a WebFinger, including HTTP, HTTPS, mailto, acct,
etc.  Each request might return a different response.  A server could try to
accommodate a sloppy client, but I don't think we should encourage that.
Clients should prepend "acct:" to form a proper URI.

Paul

> From: John Bradley [mailto:[email-masked]]
> Sent: Tuesday, May 15, 2012 8:57 PM
> To: Blaine Cook
> Cc: Paul E. Jones; [email-masked]
> OK I think where the confusion comes from was the the original WF notion
> that the host-meta template translates to static files in the directory.
> 
> If we are all good on the notion that host-meta needs to point a service
> like SWD that can deal with un-normalized input like [email-masked]'
> then I then I think we are good.
>

---

From: Melvin Carvalho <[email-masked]>
Date: Wed, 16 May 2012 15:27:23 +0200

> Clients should prepend "acct:" to form a proper URI.

Is it still possible, in practical terms, to pass in a mailto: URI to
webfinger, and be in accordance with the spec?

> > >> site only support's files with acct: then queries without it won't
> work
> > and
> > >> vica versa.
> > >>
> should
> > at

---

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 16 May 2012 09:36:29 -0400

Melvin,

There is no "normalization" process discussed in the draft.  WebFinger, by
virtue of RFC 6415, accepts a URI.  The only requirement is that a properly
formed URI is passed to host-meta (or the LRDD resource).  So, if there was
a "normalization" process as compared to SWD, it's prepending "acct:" in
front of the email address.

Paul

From: Melvin Carvalho [mailto:[email-masked]] 
Sent: Wednesday, May 16, 2012 3:09 AM
To: John Bradley
Cc: Paul E. Jones; Mark Nottingham; [email-masked]
Subject: Re: [apps-discuss] [OAUTH-WG] draft-jones-appsawg-webfinger-04

My understanding is that the W3C and IANA have a "Very high bar that must be
be met before a new URI scheme is granted."

However, it's probably a good thing that there is some oversight.  I think
one question that may reasonably be asked is 'Can this problem be solved
without creating a new URI scheme?'. I think if we take the best parts from
SWD and the best parts from WF, the answer would be yes, and also, lead to a
shorter, and more easily implemented spec.

Mark Nottinham, Dave Orchard and others will likely remember the fight over
creating a new scheme for xri as an abstract identifier almost exactly like
WF is proposing for acct:

Who know it key have just been personal, but we should be sure the IETF will
push it forward.

John B.

send

---

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 16 May 2012 10:12:18 -0400

Melvin,

Definitely.  Use of a "mailto:" URI is just as valid as any other URI.

Paul

From: Melvin Carvalho [mailto:[email-masked]] 
Sent: Wednesday, May 16, 2012 9:27 AM
To: Paul E. Jones
Cc: John Bradley; Blaine Cook; [email-masked]
Subject: Re: [apps-discuss] [OAUTH-WG] draft-jones-appsawg-webfinger-04

John, Blaine,

Paul

---

From: Blaine Cook <[email-masked]>
Date: Wed, 16 May 2012 17:34:27 +0100

I'm completely and totally opposed to webfinger not accepting
scheme-less addresses.

Please start from the user experience – no-one in the history of the
internet has typed "http://" into a browser window address bar (I may
be overstating that, but statistically speaking it's true).

Likewise, no-one will ever type "acct" or "mailto" or "xmpp" or
anything else into a form field.

To require clients to convert "[email-masked]" into
"acct:[email-masked]" is just pedantry of the worst sort. If I had it
my way, webfinger (not host-meta) wouldn't even resolve URIs; it would
only resolve scheme-less email identifiers, because that's what we're
doing.

I *understand* that there *should* be an URI for these things;
however, there is prior art for not having an URI – DNS is a core
piece of internet infrastructure that uses "bare" identifiers all the
time precisely to find *resolvable* resources that *do* use URIs.

I'm not going to stand in the way of consensus, but if the IETF
specification ends up stating that bare identifiers are not supported,
then I will personally consider this work a failure as I believe
strongly enough that URIs are not necessarily appropriate here. :-/

b.

On 16 May 2012 15:12, Paul E. Jones <[email-masked]> wrote:
> Melvin,
>
>
>
> Definitely.  Use of a “mailto:” URI is just as valid as any other URI.
>
>
>
> Paul
>
>
>

---

From: Mike Jones <[email-masked]>
Date: Wed, 16 May 2012 17:13:30 +0000

+1

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Blaine Cook
Sent: Wednesday, May 16, 2012 9:34 AM
To: Paul E. Jones
Cc: [email-masked]
Subject: Re: [apps-discuss] [OAUTH-WG] draft-jones-appsawg-webfinger-04

I'm completely and totally opposed to webfinger not accepting scheme-less addresses.

Please start from the user experience – no-one in the history of the internet has typed "http://" into a browser window address bar (I may be overstating that, but statistically speaking it's true).

Likewise, no-one will ever type "acct" or "mailto" or "xmpp" or anything else into a form field.

To require clients to convert "[email-masked]" into "acct:[email-masked]" is just pedantry of the worst sort. If I had it my way, webfinger (not host-meta) wouldn't even resolve URIs; it would only resolve scheme-less email identifiers, because that's what we're doing.

I *understand* that there *should* be an URI for these things; however, there is prior art for not having an URI – DNS is a core piece of internet infrastructure that uses "bare" identifiers all the time precisely to find *resolvable* resources that *do* use URIs.

I'm not going to stand in the way of consensus, but if the IETF specification ends up stating that bare identifiers are not supported, then I will personally consider this work a failure as I believe strongly enough that URIs are not necessarily appropriate here. :-/

b.

On 16 May 2012 15:12, Paul E. Jones <[email-masked]> wrote:
> I do not believe there is any room on the host-meta spec (RFC 6415) 
> for "bare" email addresses.  Host-meta (and thus WebFinger) operates 
> on a URI and a URI (per RFC 3986) must always have a "scheme".  An 
> email address without a scheme associated with it is just a string.
>
> On my own server, I do look for bare email addresses and prepend 
> "acct" to them.  It's functional, but why do that on the server versus 
> the client?  I implemented that since Blaine suggested it a few years 
> ago, but it also follows the practice of being strict in what you send 
> and tolerant in what you receive.   Clients should do the same.  
> Clients should send a well-formed URI.
>
> Why not just bare email addresses?  WebFinger operates on URIs.  All 
> kinds of URIs can be passed to a WebFinger, including HTTP, HTTPS, 
> mailto, acct, etc.  Each request might return a different response.  A 
> server could try to accommodate a sloppy client, but I don't think we should encourage that.
>> notion that the host-meta template translates to static files in the directory.
>>
>> service like SWD that can deal with un-normalized input like [email-masked]'
>> >> While WF dosen't require it static templates won't work 
>> >> dependably, if
>> the
>> >> least work reliably, and that requires some sort of normalization 
>> >> on
>> the
>> >> client end.
>> >
>> > I'm really not sure how you came to this conclusion? Static 
>> > host-meta files with URI templates work perfectly well to discover 
>> > the actual profile server. The template variable name is "uri", but 
>> > the spec says (or should say, if there's any confusion) that "uri" can be a "bare"
>> > the only static component is host-meta, to enable sites that can't 
>> > / don't want to host a dynamic profile server to refer clients to a

---

From: William Mills <[email-masked]>
Date: Wed, 16 May 2012 10:37:33 -0700 (PDT)

I think your assumption that we're only ever going to deal with scheme-less email identifiers is probably wrong.  I also think you're overstating the "No one ever typed... into a browser." thing.

The key question for me is, "When will discovery for acct:[email-masked] ever return different information than mailto:[email-masked]?".  I doubt there will be a difference.

Where I think the difference falls is how discovery actually happens for different types of services: web, mail, Jabber, etc..  So I think there's a glue piece we're still missing.

All that's a long winded intro to a +1 for supporting bare identifiers (because the discovery server will just have a default profile to use anyway if there is in fact a difference).

-bill

>________________________________
> From: Blaine Cook <[email-masked]>
>To: Paul E. Jones <[email-masked]>

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 16 May 2012 11:41:55 -0600

On 5/16/12 11:37 AM, William Mills wrote:
> I think your assumption that we're only ever going to deal with
> scheme-less email identifiers is probably wrong.  I also think you're
> overstating the "No one ever typed... into a browser." thing.
> 
> The key question for me is, "When will discovery for acct:[email-masked]
> ever return different information than mailto:[email-masked]?".  I doubt
> there will be a difference.
> 
> Where I think the difference falls is how discovery actually happens for
> different types of services: web, mail, Jabber, etc..  So I think
> there's a glue piece we're still missing.

At least for Jabber, we have our own protocol for discovery:

http://xmpp.org/extensions/xep-0030.html

> All that's a long winded intro to a +1 for supporting bare identifiers
> (because the discovery server will just have a default profile to use
> anyway if there is in fact a difference).

Right.

But, in any case, I think that from the Webfinger perspective there
won't be a difference: if you as an individual have both mail and jabber
services at the same domain, then it is extremely likely that your
identifier will be the same ([email-masked]) instead of having
mailto:[email-masked] and xmpp:[email-masked].

Peter

--
Peter Saint-Andre
https://stpeter.im/

---

From: William Mills <[email-masked]>
Date: Wed, 16 May 2012 10:47:25 -0700 (PDT)

The thing that *might* change is that querying for a URI might say "I only want xmpp: related endpoints.".  But that's all about how to refine the query and that doesn't require a URI scheme.

> From: Peter Saint-Andre <[email-masked]>
>To: William Mills <[email-masked]> 
>Cc: Blaine Cook <[email-masked]>; Paul E. Jones <[email-masked]>; "[email-masked]" <[email-masked]> 
>Sent: Wednesday, May 16, 2012 10:41 AM

---

From: John Bradley <[email-masked]>
Date: Wed, 16 May 2012 14:09:41 -0400

Yes that is about the services you discover.  Most of these service have schemes or there endpoints are http: so acct is not needed for that.

The one thing it would be useful for is in relation types, e.g. pointing to another related profile.  However we could have a http: URI that defines the relation type.

I understand that there is a desire to say that what you are discovering is a URI but that should not preclude relative URI like [email-masked] as long as the client can extract a host.

If the client can't extract a host then there is not much for it to do.

John B.

---

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 16 May 2012 21:22:08 -0400

Blaine,

I don't expect typical users to type "acct:" either.  This is what the client does for the user.  It's the same thing as what most browsers do today.

But, the scheme is used by us geeks.  You enter http: or https: when using XHR to open a web page.  You'll use "mailto:" when embedding a link in a web page.

I would never expect users to type "acct:" in the login box for OpenID.  Never.  But, don't confuse user behavior with proper protocol behavior.

Paul

> From: Blaine Cook [mailto:[email-masked]]
> Sent: Wednesday, May 16, 2012 12:34 PM
> To: Paul E. Jones
> Cc: Melvin Carvalho; John Bradley; [email-masked]
> internet has typed "http://" into a browser window address bar (I may be
> overstating that, but statistically speaking it's true).
> 
> "acct:[email-masked]" is just pedantry of the worst sort. If I had it my
> way, webfinger (not host-meta) wouldn't even resolve URIs; it would only
> resolve scheme-less email identifiers, because that's what we're doing.
> 
> I *understand* that there *should* be an URI for these things; however,
> there is prior art for not having an URI – DNS is a core piece of internet
> infrastructure that uses "bare" identifiers all the time precisely to find
> *resolvable* resources that *do* use URIs.
> 
> then I will personally consider this work a failure as I believe strongly
> enough that URIs are not necessarily appropriate here. :-/
> 
> b.
>

---

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 16 May 2012 21:39:39 -0400

William,

You asked...

“The key question for me is, "When will discovery for acct:[email-masked] ever return different information than mailto:[email-masked]?".  I doubt there will be a difference.”

An example would be if you query an account like acct:[email-masked].  You might get useful information about that account.  However, querying mailto:[email-masked] should return 404.

Paul

From: William Mills [mailto:[email-masked]] 
Sent: Wednesday, May 16, 2012 1:38 PM
To: Blaine Cook; Paul E. Jones
Cc: [email-masked]
Subject: Re: [apps-discuss] [OAUTH-WG] draft-jones-appsawg-webfinger-04

-bill

---

From: William Mills <[email-masked]>
Date: Wed, 16 May 2012 20:04:29 -0700 (PDT)

That's what the design is as you see it.  Why do you need to return different results?  What is the justification?

> From: Paul E. Jones <[email-masked]>
>To: 'William Mills' <[email-masked]>; 'Blaine Cook' <[email-masked]> 
>Sent: Wednesday, May 16, 2012 6:39 PM
>Subject: RE: [apps-discuss] [OAUTH-WG] draft-jones-appsawg-webfinger-04
> 
>
>William,
> 
>You asked...
> 
>From:William Mills [mailto:[email-masked]]

---

From: "Paul E. Jones" <[email-masked]>
Date: Thu, 17 May 2012 00:08:28 -0400

Twitter does not have email addresses, so what would be the justification in returning something that’s not right?

From: William Mills [mailto:[email-masked]] 
Sent: Wednesday, May 16, 2012 11:04 PM
To: Paul E. Jones; 'Blaine Cook'
Cc: [email-masked]
Subject: Re: [apps-discuss] [OAUTH-WG] draft-jones-appsawg-webfinger-04

  _____  

William,

You asked...

Paul

-bill

---

From: William Mills <[email-masked]>
Date: Wed, 16 May 2012 21:10:59 -0700 (PDT)

The real question is when would you ever want to return different non-error results?

>Sent: Wednesday, May 16, 2012 9:08 PM
>>From:Paul E. Jones <[email-masked]>

---

From: "Paul E. Jones" <[email-masked]>
Date: Thu, 17 May 2012 00:25:32 -0400

For URI schemes that all belong to the same person, I would expect the same results or a 404 if the specific service is not supported.  It’s important that we allow a 404 since some accounts may not support email or XMPP or whatever other protocol is of interest.

This brings us back to a point of discussion we had in recent weeks, though: why would we want to provide a positive answer for every URI scheme?  My server currently returns a positive answer for anything that looks like scheme:[email-masked].  That’s not right.  I should not do that.  There’s no such thing as qqqqbit:[email-masked], but my server responds like there is.

What we’re often seeking with WF is information about user accounts, thus the “acct” URI scheme.  We’re not usually seeking info about email addresses or XMPP addresses or other user@domain styles.  And, schemes are important.  If you believe otherwise, then you might think this is perfectly good HTML:

You can <a href=”[email-masked]”>email me</a> or <a href=”[email-masked]”>IM me</a>.

In any case, WF does not preclude one from querying using a mailto URI scheme and some protocols (e.g., OpenID Connect) could declare that mailto must be supported by WF.  I have no objection to that.  However, if I want to query for information about an account, mailto is not right.  That’s not the right scheme to use if I want to get information about a photo album at a photo sharing site or an account at a file sharing site.  There might be user identifiers for those accounts, but they are not going to be my email ID.

Paul

Sent: Thursday, May 17, 2012 12:11 AM

  _____  

 

  _____  

William,

You asked...

Paul

-bill

---

From: Graham Klyne <[email-masked]>
Date: Wed, 16 May 2012 08:16:47 +0100

> get rejected on the grounds that somebody somewhere decided there shall be

There is no policy of "no new URI schemes".

There are some who say that the http: scheme *is* all that is needed, and in a 
purely technical sense they are generally correct.  But naming is a social and 
practical as well as technical issue, so the technical concerns are not the 
whole story.  Using HTTP has the significant advantage that almost any networked 
system can easily retrieve information about the URI, enabling a 
follow-your-nose discovery process (assuming such information is published).

Thus there is a tendency for new schemes to be examined closely to see if they 
really offer any operational capability that would be harder achieve using 
existing schemes.

The bar for provisional registration of a new scheme is low, and you could 
probably request this now.

I don't know about the particulars of your proposed acct: scheme, but as a 
thought experiment, does it achieve anything that could not be achieved as 
easily with (something like):
    http://acct.example.org/<your string here>
?

(Bearing in mind that it does not matter that the http://acct.example.org/ URI 
may be not dereferencable.)

...

There's an interesting maybe-comparable example to consider: Digital Object 
Identifiers.  Several years ago, these were defined to provide a way for 
allocating unique identifiers to research publications, etc. 
(http://www.doi.org/, http://en.wikipedia.org/wiki/Digital_object_identifier).

A doi: URI scheme was proposed but has not subsequently been approved for 
registration (http://human.freescience.org/htmx/digital_object_identifier.php); 
rather the doi was registered as a sub-namespace in another new URI scheme, 
info: (http://www.ietf.org/rfc/rfc4452.txt) which was defined as an umbrella for 
several of these "non-web" identifiers.

But it's interesting that a DOI is most commonly cited in a web page and similar 
contexts, and often in print, as http://dx.doi.org/<handle> 
(http://www.doi.org/doi_handbook/2_Numbering.html#2.6.2) ... so the other URI 
scheme registrations don't seem to have that much traction.

#g
--

(I am currently designated reviewer for URI scheme registration requests, but 
this comment is offered in a personal capacity.)

On 16/05/2012 00:02, Paul E. Jones wrote:
>>> On Mon, May 14, 2012 at 2:20 AM, John Bradley<[email-masked]>  wrote:
>>> there, and that links cannot read<a href="acct:user@host">me</a>  and

---

From: Melvin Carvalho <[email-masked]>
Date: Thu, 17 May 2012 11:52:45 +0200

On 16 May 2012 09:16, Graham Klyne <[email-masked]> wrote:

> There are some who say that the http: scheme *is* all that is needed, and
> in a purely technical sense they are generally correct.  But naming is a
> social and practical as well as technical issue, so the technical concerns
> are not the whole story.  Using HTTP has the significant advantage that
> almost any networked system can easily retrieve information about the URI,
> enabling a follow-your-nose discovery process (assuming such information is
> published).
>
> Thus there is a tendency for new schemes to be examined closely to see if
> they really offer any operational capability that would be harder achieve
> using existing schemes.
>
> (Bearing in mind that it does not matter that the http://acct.example.org/URI may be not dereferencable.)
>

Facebook do something quite similar to this with
graph.facebook.com/user... my suggestion from the webfinger list was
http://host/@/user, but there are possible deployment issues.

One tricky thing with the approach suggested, is that you dont know whether
you will be dealing with http or https until you try, so there's
potentially an extra round trip.

> ...
>
> There's an interesting maybe-comparable example to consider: Digital
> Object Identifiers.  Several years ago, these were defined to provide a way
> for allocating unique identifiers to research publications, etc. (
> http://www.doi.org/, http://en.wikipedia.org/wiki/**
> Digital_object_identifier<http://en.wikipedia.org/wiki/Digital_object_identifier>
> ).
>
> registration (http://human.freescience.org/**htmx/digital_object_**
> identifier.php<http://human.freescience.org/htmx/digital_object_identifier.php>);
> info: (http://www.ietf.org/rfc/**rfc4452.txt<http://www.ietf.org/rfc/rfc4452.txt>)
> which was defined as an umbrella for several of these "non-web" identifiers.
>
> But it's interesting that a DOI is most commonly cited in a web page and
> similar contexts, and often in print, as http://dx.doi.org/<handle> (
> http://www.doi.org/doi_**handbook/2_Numbering.html#2.6.**2<http://www.doi.org/doi_handbook/2_Numbering.html#2.6.2>)
> ... so the other URI scheme registrations don't seem to have that much
> traction.
>
> #g
> --
>
> (I am currently designated reviewer for URI scheme registration requests,
> but this comment is offered in a personal capacity.)
>
>
>
>>> From: [email-masked] [mailto:apps-discuss-bounces@**
>>> ietf.org <[email-masked]>]
>>> Subject: Re: [apps-discuss] [OAUTH-WG] draft-jones-appsawg-webfinger-**
>>> 04
>>>
>>> Hi Paul,
>>>
>>>>> In WF the premise was to have a simple server supporting static
>>>>>
>>>> documents.
>>>
>>>> https://host/.well-known/host-**meta?resource=acct:user@host<https://host/.well-known/host-meta?resource=acct:user@host>
>>>> .
>>>>
>>>>  getting acct: registered or WF through the approval process with it
>>>>>
>>>> will not be a walk in the park.
>>>
>>>>
>>>> https://host/.well-known/host-**meta?resource=acct:user@host<https://host/.well-known/host-meta?resource=acct:user@host>as the
>>>> draft-jones-appsawg-webfinger-**04 to a common, merged,
>>>> draft-jones-simple-web-**discovery-03. I think renaming webfinger to
>> ______________________________**_________________
>> https://www.ietf.org/mailman/**listinfo/apps-discuss<https://www.ietf.org/mailman/listinfo/apps-discuss>
>>
>>  ______________________________**_________________
> https://www.ietf.org/mailman/**listinfo/apps-discuss<https://www.ietf.org/mailman/listinfo/apps-discuss>
>

---

From: Michiel de Jong <[email-masked]>
Date: Thu, 17 May 2012 13:42:39 +0200

How about if we chop it up:

- We allow bare "user@host" (without acct: prefix), and also "any URI".

Note that there is no name clash here, a URI always has a ':' in
there, and "user@host" never does. Seems like a simple solution to me.
In the webfinger/swd spec we don't mention whether acct:user@host is a
URI or not, since this would risk throwing out the child with the bath
water if it gets rejected. So, we leave that out of scope. We build
other specs (OStatus, OAuth, remoteStorage) on top of this super
simple atomic spec that does 'one thing well'.

- Then we still persue acct: as a URI scheme, but in a /separate/ spec.

If it gets approved, we will have both. If it does not, then at least
we can still do discovery, and we have to bring the future of OStatus,
OAuth and remoteStorage into doubt because of this small, definitely
useful, but also unstable detail.

My 2ct,
Michiel

---

From: Graham Klyne <[email-masked]>
Date: Thu, 17 May 2012 14:05:08 +0100

On 17/05/2012 10:52, Melvin Carvalho wrote:
>> >  (Bearing in mind that it does not matter that thehttp://acct.example.org/URI  may be not dereferencable.)
>> >

If the URI is being used primarily for identification purposes, and is not used 
operationally for dereferencing as-is, that seems a minor issue.  If the http: 
URI is also used to serve as a route to "follow-your-nose" high-level 
information, why would it be published using https?

#g
--

---

From: "Paul E. Jones" <[email-masked]>
Date: Thu, 17 May 2012 09:30:08 -0400

We could always do that sort of thing as a last resort, but I don't think we should plan for that approach.

There is value in not only querying the acct URI for a user, but also having link relations pointing to the users other accounts.

Why is there a concern over prefixing acct on what the user enters? URI schemes exist for a reason. I don't like assumptions in protocols.

Paul 

_____________________________________________
From: Michiel de Jong <[email-masked]>
Sent: Thu May 17 07:42:39 EDT 2012
To: "Paul E. Jones" <[email-masked]>
Cc: William Mills <[email-masked]>, Blaine Cook <[email-masked]>, [email-masked]
Subject: Re: [apps-discuss] [OAUTH-WG] draft-jones-appsawg-webfinger-04

My 2ct,
Michiel

---

From: John Bradley <[email-masked]>
Date: Thu, 17 May 2012 10:43:05 -0400

Graham,

The use of acct: is not dissimilar to the proposed use in Handle or XRI    

It provides a new namespace for Identifiers and uses its own resolver WF to deference them to http uri for retrieval.

Arguably Handle and XRI added persistence and other arguments that are not present in acct:/WF.

As far as linking to a XRD document using acct: requiring the use of the WF resolver the XRD can just as easily contain the http URI enabling direct access.

I can't see the requirement for a new scheme based simply on needing a new link relationship.

Someone will also eventually notice that we are effectively duplicating the existing http: syntax for naming a user at a domain "http://[email-masked]".

If acct: is used simply as an identifier, that is never intended for a user to type then the argument for a new scheme is weak.

If acct: is intended to be a new name resolution protocol (It is) then it is causing namespace fragmentation and breaking the semantic web.

I have had the W3C TAG intervene on OASIS standards wanting to register a new scheme so I am cautious.

Registering acct: vs info:acct: is important from a browser behaviour point of view if a user clicks on a link.
What browser support do people anticipate for WF?   Do people expect to place acct:[email-masked] as a link in a html document and have something useful happen if the user clicks on it?
I know we did in XRI, and that was part of the scheme justification.

WF should start the registration process for acct: now to enable the inevitable wider debate.

Until there is at least a provisional registration, we probably should not make the scheme registration a requirement in the proposed starting document.

John B.

On 2012-05-17, at 9:05 AM, Graham Klyne wrote:

> If the URI is being used primarily for identification purposes, and is not used operationally for dereferencing as-is, that seems a minor issue.  If the http: URI is also used to serve as a route to "follow-your-nose" high-level information, why would it be published using https?
> 
> #g
> --

---

From: Michiel de Jong <[email-masked]>
Date: Thu, 17 May 2012 17:00:56 +0200

Hi Paul,

On Thu, May 17, 2012 at 3:30 PM, Paul E. Jones <[email-masked]> wrote:
> There is value in not only querying the acct URI for a user, but also having
> link relations pointing to the users other accounts.

Yes! there is. But that's no reason to not split the two specs.
Discovery described by one spec, and new acct: scheme proposed in a
separate spec.

> Why is there a concern over prefixing acct on what the user enters? URI
> schemes exist for a reason. I don't like assumptions in protocols.
>
> Paul
>

Once acct: is a URI scheme, you'll be able to say the parameter takes
"any URI". Until then, you'll have two options:

1) say the parameter takes "any URI or user@host"
2) say the parameter takes "any existing URI scheme or acct:user@host"

During the time that the acct: scheme is pending, opting for 2 has no
advantage in terms of assumptions/orderliness of the protocol. And if
the scheme gets rejected, then it will be seen as webfinger being
rejected, which will then domino to OAuth discovery, OStatus and
remoteStorage being rejected. That's how people will receive such a
rejection i think.

I would say hedge the brands, so webfinger/swd has no mention of the
string 'acct:', and therefore cannot be negatively affected by a
possible rejection of acct: as a URI scheme.

If acct: does get accepted, then after that we can still choose to
deprecate bare user@host in favour of the newly accepted URI scheme.
But that may take what, years, probably? Until then, i think it's
safer to keep the two things separate, to avoid the risk of "rejection
domino".

---

From: William Mills <[email-masked]>
Date: Thu, 17 May 2012 10:16:38 -0700 (PDT)

So we're using scheme here to refine the information returned, but we could as easily refine the information to be returned in a separate value.  We're overloading this on the user specifier.

For the most part from my perspective what I want to discover is the OAuth endpoints.  In some ways that's always appropriate for a user in a namespace you own.  Having the WF server have to know all possible services supported doesn't seem ideal.  I think there's an argument to make that returning the authentication endpoint information is something you should always do for accounts in your namespace.

-bill

>Sent: Wednesday, May 16, 2012 9:25 PM

---

From: John Bradley <[email-masked]>
Date: Thu, 17 May 2012 13:25:31 -0400

For openID Connect we only need WF to return a URI for the openID Connect issuer.   That is then used to get the OAuth info.   
Putting service information directly into a users discovery document turned out to be a bad idea for maintenance in Yadis and XRI 2.0.

The user doc needs to reference the service provider, that provider is authoritative for it's own config.

in your IMAP case you may or may not be using the connect OAuth service, there would probably be a specifc relationship for the Oauth provider that grants IMAP tokens.

John B.

---

From: Mike Jones <[email-masked]>
Date: Thu, 17 May 2012 17:32:38 +0000

+1

From: Michiel de Jong
Sent: 5/17/2012 8:01 AM

Hi Paul,

---

From: "Paul E. Jones" <[email-masked]>
Date: Thu, 17 May 2012 14:31:34 -0400

John,

The "acct" URI would not be typed into an OpenID login box, but that does
not mean it would never be used.  Users do not usually type in "xmpp:" or
"mailto:", either, but they are nonetheless useful.  The "acct" URI scheme
would be used similarly.  The query over the wire would request the XRD/JRD
document for the account identified by that acct URI.

Further, inside the XRD/JRD document, there may be link relations that allow
a user to reference his or her other accounts at various services.  These
references might allow WF queries to span across multiple domains and learn
information such as where my photo stream is located, where my public file
storage is located, etc.  It is a means of linking social networking
accounts, etc.  I have this example earlier:

These "href" values all refer to some kind of URI.  No current URI scheme is
appropriate.  We can slaughter an existing one, but it's not the right
solution, IMO.

Paul

Sent: Thursday, May 17, 2012 10:43 AM
To: Graham Klyne

Graham,

The use of acct: is not dissimilar to the proposed use in Handle
<http://www.itu.int/osg/csd/emerging_trends/handle_system/index.html>  or
XRI <http://docs.oasis-open.org/xri/2.0/specs/xri-resolution-V2.0.html>     

It provides a new namespace for Identifiers and uses its own resolver WF to
deference them to http uri for retrieval.

Arguably Handle and XRI added persistence and other arguments that are not
present in acct:/WF.

As far as linking to a XRD document using acct: requiring the use of the WF
resolver the XRD can just as easily contain the http URI enabling direct
access.

I can't see the requirement for a new scheme based simply on needing a new
link relationship.

Someone will also eventually notice that we are effectively duplicating the
existing http: syntax for naming a user at a domain
"http://[email-masked]".

If acct: is used simply as an identifier, that is never intended for a user
to type then the argument for a new scheme is weak.

If acct: is intended to be a new name resolution protocol (It is) then it is
causing namespace fragmentation and breaking the semantic web.

I have had the W3C TAG intervene on OASIS standards wanting to register a
new scheme so I am cautious.

Registering acct: vs info:acct: is important from a browser behaviour point
of view if a user clicks on a link.

What browser support do people anticipate for WF?   Do people expect to
place acct:[email-masked] as a link in a html document and have something
useful happen if the user clicks on it?

WF should start the registration process for acct: now to enable the
inevitable wider debate.

Until there is at least a provisional registration, we probably should not
make the scheme registration a requirement in the proposed starting
document.

John B.

>  (Bearing in mind that it does not matter that
thehttp://acct.example.org/URI  may be not dereferencable.)

If the URI is being used primarily for identification purposes, and is not
used operationally for dereferencing as-is, that seems a minor issue.  If
the http: URI is also used to serve as a route to "follow-your-nose"
high-level information, why would it be published using https?

#g

---

From: "Martin J. Dürst" <[email-masked]>
Date: Fri, 18 May 2012 18:05:04 +0900

On 2012/05/16 16:16, Graham Klyne wrote:

> Object Identifiers. Several years ago, these were defined to provide a
> way for allocating unique identifiers to research publications, etc.
> (http://www.doi.org/,
> http://en.wikipedia.org/wiki/Digital_object_identifier).
>
> A doi: URI scheme was proposed but has not subsequently been approved
> for registration
> (http://human.freescience.org/htmx/digital_object_identifier.php);
> rather the doi was registered as a sub-namespace in another new URI
> scheme, info: (http://www.ietf.org/rfc/rfc4452.txt) which was defined as
> an umbrella for several of these "non-web" identifiers.
>
> similar contexts, and often in print, as http://dx.doi.org/<handle>
> (http://www.doi.org/doi_handbook/2_Numbering.html#2.6.2) ... so the
> other URI scheme registrations don't seem to have that much traction.

Things like these happen mostly because new URI(/IRI) schemes are hard 
to deploy. That initially led to a lot of pressure against new schemes, 
but those who liked to invent new schemes didn't get convinced, so those 
whot didn't think new schemes were such a good idea just switched from a 
"we know, and we don't want you to find out the hard way" to a "let them 
find out themselves, we told you so" policy.

Of course, what I wrote didn't happen explicitly, but I hope it 
describes the general developments well. One reason for the change may 
be that when URIs were not that well known yet, those who invented them 
felt that they had to protect users from bad experiences. These days, 
URIs as such are extremely well established, and there isn't much of a 
danger anymore that a failure with a specific URI gets blamed on URIs in 
general.

Regards,   Martin.

---

From: "Martin J. Dürst" <[email-masked]>
Date: Fri, 18 May 2012 19:26:17 +0900

This is a good point. Remember that email itself doesn't need nor use 
mailto:. It's HTML and other locations where mailto: is used.

Regards,   Martin.

On 2012/05/18 3:31, Paul E. Jones wrote:
> XRI<http://docs.oasis-open.org/xri/2.0/specs/xri-resolution-V2.0.html>
>
>
>

---

From: "Martin J. Dürst" <[email-masked]>
Date: Fri, 18 May 2012 19:38:11 +0900

> Someone will also eventually notice that we are effectively duplicating the existing http: syntax for naming a user at a domain "http://[email-masked]".

No. In http://[email-masked], the "jbradley" part is (or mostly, was) 
used to indicate that you are *connecting* to foo.com as user jbradley. 
This is of no use if others want to find information *about* you(r account).

> I have had the W3C TAG intervene on OASIS standards wanting to register a new scheme so I am cautious.

I haven't followed that debate closely, but from what I have seen, there 
are HUGE differences between XRI and acct. acct has a reasonably narrow 
purpose. XRI, on the other hand, had very far-reaching goals, and was 
presented as "URIs done better", with a lot of hype.

> WF should start the registration process for acct: now to enable the inevitable wider debate.

Yes, please start. I don't expect too many problems. If you look at the 
list of registered schemes, there are already many.

Regards,    Martin.