Subject: [apps-discuss] Webfinger discussion

From: "Paul E. Jones" <[email-masked]>
Date: Mon, 26 Mar 2012 10:35:54 -0400

Folks,

I saw the notes regarding the Webfinger discussion today.  Unfortunately, I
could not be there, so please indulge me while I ask questions related to
the notes:

> Thomas Roessler: CORS is in last call

This is good to know.  So, was the group in favor of leaving it in as
mandatory?

?: Good idea.  Work going on in other orgs that reference this.

> Hannes Tschofenig: People like the whole idea, but is bizarre to mandate
CORS

Yeah, we have a choice to make.  If we mandate it, then (in theory) it
should be possible to query a Webfinger server via a JavaScript application
in the browser.  Without it, we would not be able to get beyond the
single-origin rules.

> Paul Hoffman: needs to have consensus calls, so should be in APPSAWG

Not sure what this meant.  Are you suggesting we make the document a WG
item?  For sure, I'd like to progress the document.

> Leif Johannsen: people don't have their own email servers anymore

This is true, which is one reason people have favored using "acct".  Now,
people have identifiers on social networks, but the user@domain notation is
convenient and understood.

> Andrew Sullivan: when I was a kid, they told us to turn off finger, so I'm
> concerned about security

That was due to the fact the finger protocol implementations had security
holes.  It was also possible to do things like "ln /etc/password .plan" and
that was a bad thing :-)

> Dave Crocker: email is the same as it's always been.  Email is good as
> identifier, even if there's no mailbox.  Nice service to have, but needs
> lots of input to get correct.  Might need more work than APPSAWG.  Might
> need its own WG.

I would hope it does not go so far as to needing its own WG.  Much of the
"Webfinger" functionality is really formally describing it as such and using
existing RFCs.  The "new" bits are the "acct" URI scheme, link relation,
requirement to use CORS, and requirement to implement JRD.  The "acct" URI
scheme is already used "in the wild" and is needed because some social
networks provide user accounts, but not email addresses.  To somebody else's
point, some do not run their own email servers anymore and certainly many
social networks are not going to provide email services, as there is little
to no value in doing so.  Yet, a "Webfinger" service has value.

> Mike Jones: (speaking as openid/oauth contributer) we don't use this;
> it doesn't have the right properties

Webfinger is not intended to be used by OpenID directly.  Actually, how I
stumbled into this area, though, was through OpenID.  As I implemented my
OpenID server, I wanted to find a way to get rid of forcing people to have
OpenID identifiers that had to enter on sites like
https://openid.packetizer.com/paulej.  People pointed me to the work on
Webfinger.  Webfinger does not replace the OpenID identifier, but merely
provides makes it easily discoverable.  So, when I visit a web site, I can
enter [email-masked].  This would result in a Webfinger query for
acct:[email-masked].  What would be returned is several pieces of
information one of which is https://openid.packetizer.com/paulej using the
link relation http://specs.openid.net/auth/2.0/provider.  (I'm not too
favorable to that particular link relation, since it's not a pointer to the
provider, but a pointer to my identifier.  But, that seems to be the
predominant value used.)  The service I'm trying to log into now has my
identifier in hand and would go through the same login procedures.  Security
should not be compromised, because the Webfinger account information should
have been provided securely and the login process within the OpenID provider
should either be automatic (because the provider already recognizes your
browser) or would prompt for credentials.  Nothing about OpenID has been
weakened in the process, as nothing about OpenID changed.  Further, there is
never a requirement to use Webfinger -- it's an option for OpenID.

> John Bradley: (speaking as author of XRD) JRD is doc'd in blog post,
> concerned about security/privacy, needs more work before could be used
> in OpenID/Connect.

JRD is documented now in standards-track RFC 6415.  It defines a direct
mapping from XRD to JRD.  I will not disagree that thought may need to be
considered in for use in OpenID or OpenID Connect, but that is not an issue
for Webfinger itself.  Webfinger merely provides pointers to information or
other identifiers.  I understand how this would work in OpenID and I don't
see risk there.  I'm not familiar with how OpenID Connect is supposed to
work.  I had seen some proposals, but nothing recent.  Those proposals I had
seen suggested that I enter my credentials for my identify provider on the
site that I was visiting.  Hopefully, that's now how it works now, because
there's no way I would do that :-)

So, what was the opinion of the group?  It's important to note that RFC 6415
essentially defines all of the mechanisms already, so it's out there and
people can use it.  The Webfinger draft is there to formalize the name and
to introduce the needed "acct" URI and link relation values.

Paul

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 26 Mar 2012 11:05:57 -0400

> holes.  It was also possible to do things like "ln /etc/password .plan" and

That wasn't the only reason they told us this.  One of the things that
people used to worry about was that finger leaked information.  In
particular, it was an excellent way to identify targets for account
takeover: people who never logged in, and people who were in for
endless days and therefore whose account was probably often
unmonitored.

Now, I never knew whether I believed this sort of complaint, but it
was one, and the draft as it stands only just hints at the sort of
analysis that ought to be done.  It seems like this requires a much
expanded security considerations section, and that was the point I
wanted to make.

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: "Paul E. Jones" <[email-masked]>
Date: Mon, 26 Mar 2012 14:15:31 -0400

Andrew,

> > > Andrew Sullivan: when I was a kid, they told us to turn off finger,
> > > so I'm concerned about security
> >
> > That was due to the fact the finger protocol implementations had
> > security holes.  It was also possible to do things like "ln
> > /etc/password .plan" and that was a bad thing :-)
> 
> takeover: people who never logged in, and people who were in for endless
> days and therefore whose account was probably often unmonitored.
> 
> Now, I never knew whether I believed this sort of complaint, but it was
> one, and the draft as it stands only just hints at the sort of analysis
> that ought to be done.  It seems like this requires a much expanded
> security considerations section, and that was the point I wanted to make.

I can see those argument against the traditional finger protocol.  At the
very least, one could determine which accounts have not changed passwords
since the last attack attempt.

For Webfinger, though, those same security issues do not exist.  It borrows
the concept of learning information about somebody (or something), but it's
certainly not exposing the same risks.

Further, whatever risks exist for Webfinger exist with RFC 6415, largely.
The acct URI, acct link relation, and use of CORS are two new
considerations, but everything else already exists.

So for the security considerations, we need to focus on those items.  I'm
happy to add whatever folks feel we should add.

Paul

---

From: Bob Wyman <[email-masked]>
Date: Mon, 26 Mar 2012 14:31:30 -0400

> endless days and therefore whose account was probably often
WebFinger has primarily been used for providing access to relatively static
data rather than for the kind of dynamic "presence" information that finger
was often used for. Thus, when folk are thinking about WebFinger, they are
usually considering use cases like "locating a user's blog," or "finding a
user's public key." However, there isn't anything in WebFinger that would
prevent providing dynamic data such as "current location (lat/long),"
"logged in state," or even "last command issued to bash..." (highly
un-recommended!). If people did, in fact, use WebFinger to record such
stuff, the concerns you mentioned would be relevant. Thus, it might make
sense for the Security Considerations section to suggest that one should
think carefully before using WebFinger to provide such dynamic information.

> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss
>

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 27 Mar 2012 00:30:39 +0200

On 3/26/12 8:31 PM, Bob Wyman wrote:
> 
> 
> On Mon, Mar 26, 2012 at 11:05 AM, Andrew Sullivan
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     security
> WebFinger has primarily been used for providing access to relatively
> static data rather than for the kind of dynamic "presence" information
> that finger was often used for. Thus, when folk are thinking about
> WebFinger, they are usually considering use cases like "locating a
> user's blog," or "finding a user's public key." However, there isn't
> anything in WebFinger that would prevent providing dynamic data such as
> "current location (lat/long)," "logged in state," or even "last command
> issued to bash..." (highly un-recommended!). If people did, in fact, use
> WebFinger to record such stuff, the concerns you mentioned would be
> relevant. Thus, it might make sense for the Security Considerations
> section to suggest that one should think carefully before using
> WebFinger to provide such dynamic information.

We already have protocols for such dynamic publish/subscribe features
(and those protocols include ways to authorize who can see what).
Webfinger might provide pointers to locations where one could subscribe
to dynamic data, but AFAIK it would not be used to pull the data.

Peter

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

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 27 Mar 2012 04:47:10 -0400

> think carefully before using WebFinger to provide such dynamic information.

Right, that's most of what I was trying to say.  I do have a concern
that collecting a bunch of different information about a given person
and linking it together in a single, easy to access repository has
some potential security side effects (not just privacy ones, but those
too, of course) that are not clearly highlighted in the security
considerations.  I suppose one could argue that facebook's (or pick
your poison) user population shows nobody cares about that, but I
think it would still be good to have some observations about those
effects.

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: John C Klensin <[email-masked]>
Date: Tue, 27 Mar 2012 06:52:31 -0400

--On Tuesday, March 27, 2012 04:47 -0400 Andrew Sullivan
<[email-masked]> wrote:

> I suppose one could argue that facebook's (or pick
> your poison) user population shows nobody cares about that,
> but I think it would still be good to have some observations
> about those effects.

While Facebook (and others who think that Facebook-style social
networks are taking over the world, or that the world is turning
into them) are fond of making that inference, I think we need to
keep in mind that the total number of active Facebook users
remains a very small fraction of the number of people who are
using the Internet and who could, in principle, join Facebook.
Statistically, we know just nothing about that larger population
and what they do and do not care about.  We don't even know what
fraction of them are not on Facebook because of those concerns.

    john

---

From: "Paul E. Jones" <[email-masked]>
Date: Tue, 27 Mar 2012 12:15:21 -0400

I agree it would be useful to add text about sharing information that might
be dynamic in nature (e.g., current user location).

We'll add text along those lines to the next draft.  Any other security
considerations we should note?

Paul

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> On Behalf Of Andrew Sullivan
> Sent: Tuesday, March 27, 2012 4:47 AM
> To: [email-masked]
> Subject: Re: [apps-discuss] Webfinger discussion
> 
> > stuff, the concerns you mentioned would be relevant. Thus, it might
> > make sense for the Security Considerations section to suggest that one
> > should think carefully before using WebFinger to provide such dynamic
> information.
> 
> Right, that's most of what I was trying to say.  I do have a concern that
> collecting a bunch of different information about a given person and
> linking it together in a single, easy to access repository has some
> potential security side effects (not just privacy ones, but those too, of
> course) that are not clearly highlighted in the security considerations.
> I suppose one could argue that facebook's (or pick your poison) user
> population shows nobody cares about that, but I think it would still be
> good to have some observations about those effects.
> 
> Best,
> 
> A
> 
> --
> Andrew Sullivan
> [email-masked]

---

From: James M Snell <[email-masked]>
Date: Tue, 27 Mar 2012 09:39:25 -0700

To be fair, there are ways of dealing with the potential for security
leaks of this nature with WebFinger that did not really exist with the
original Finger protocol. OAuth 2, for instance. A WebFinger endpoint
could choose to serve up only the most basic static information to
unauthenticated requesters, but then provide a means for a requester
to authenticate and request permission from the target user or
provider to acquire additional information as part of the response.

On a side note to Paul: I did have some additional general comments on
the WebFinger spec itself, I wanted to ask where such comments would
be best directed for discussion.

- James

---

From: "Paul E. Jones" <[email-masked]>
Date: Tue, 27 Mar 2012 12:57:31 -0400

James,

If the other items are editorial, perhaps just direct them to me.  If they are items that others might want to weigh in on, then this list is the appropriate venue.

Paul

> From: James M Snell [mailto:[email-masked]]
> Sent: Tuesday, March 27, 2012 12:39 PM
> To: Paul E. Jones
> Cc: Andrew Sullivan; [email-masked]
> unauthenticated requesters, but then provide a means for a requester to
> authenticate and request permission from the target user or provider to
> acquire additional information as part of the response.
> 
> On a side note to Paul: I did have some additional general comments on the
> WebFinger spec itself, I wanted to ask where such comments would be best
> directed for discussion.
> 
> - James
> 
> > I agree it would be useful to add text about sharing information that
> > might be dynamic in nature (e.g., current user location).
> >
> > We'll add text along those lines to the next draft.  Any other
> > security considerations we should note?
> >
> > Paul
> >
> >> > un-recommended!). If people did, in fact, use WebFinger to record
> >> > such stuff, the concerns you mentioned would be relevant. Thus, it
> >> > might make sense for the Security Considerations section to suggest
> >> > that one should think carefully before using WebFinger to provide
> >> > such dynamic
> >> information.
> >>
> >> some potential security side effects (not just privacy ones, but
> >> those too, of
> >> population shows nobody cares about that, but I think it would still
> >> be good to have some observations about those effects.
> >>
> >> Best,
> >>
> >> A
> >>
> >> --
> >> Andrew Sullivan
> >> [email-masked]

---

From: Bob Wyman <[email-masked]>
Date: Tue, 27 Mar 2012 13:00:26 -0400

> (and those protocols include ways to authorize who can see what).
Certainly there are other protocols that are much better suited for the
sharing of dynamic information than is WebFinger. However, it is generally
the case that if a protocol *can* be used to address some need, it*
will*be used to address that need. Thus, I think we need to anticipate
that some
folk will, in fact, share dynamic information with WebFinger even if it is
not the optimal protocol for that purpose. Folk will do this for no other
reason than that they will wish to minimize the complexity of their
implementations by doing as much as they can with one mechanism. Others
will do it because they don't know of the alternatives.

I support the inclusion of pointers in the WebFinger spec to other
protocols that are better suited for the sharing of dynamic, rapidly
changing information.

---

From: Bob Wyman <[email-masked]>
Date: Tue, 27 Mar 2012 13:18:08 -0400

Paul,
Examples are very powerful means of setting expectations for usage of
standards... So, perhaps it would be useful to include in the examples a
pointer to a user's "pres:" URI, defined by RFC3859 "Common Profile for
Presence", as the endpoint that should be used to obtain "presence"
information.

bob wyman

On Tue, Mar 27, 2012 at 12:57 PM, Paul E. Jones <[email-masked]>wrote:

> James,
>
> If the other items are editorial, perhaps just direct them to me.  If they
> are items that others might want to weigh in on, then this list is the
> appropriate venue.
>
> Paul
>
> the

---

From: "Paul E. Jones" <[email-masked]>
Date: Tue, 27 Mar 2012 14:06:07 -0400

Bob,

Is "pres:" being used in practice?  Does it refer to SIP or XMPP or other
presence protocol?

I'll note that adding this one might incite additional concerns for privacy.
I assume that whatever protocol to which pres: refers (which is unclear to
me) would handle the authorization aspects.  But, I'm left wondering. if one
knows a person's SIP or XMPP URI, why would one need pres:?

Paul

From: [email-masked] [mailto:[email-masked]] On Behalf Of Bob Wyman
Sent: Tuesday, March 27, 2012 1:18 PM
To: Paul E. Jones
Cc: [email-masked]
Subject: Re: [apps-discuss] Webfinger discussion

Paul,

bob wyman

On Tue, Mar 27, 2012 at 12:57 PM, Paul E. Jones <[email-masked]>
wrote:

James,

Paul

---

From: Bob Wyman <[email-masked]>
Date: Tue, 27 Mar 2012 14:13:12 -0400

im: and pres: were defined as protocol independent URI's in order to make
things simpler than having to work with XMPP, SIP, and potentially even
APEX, etc. as alternative presence or messaging protocols. But, yeah...
nobody seems to use the stuff. The fact remains that messaging and presence
are still distinct services. So, perhaps an xmpp: URI tagged as both
"instant-messaging" and "presence" would make more sense.

bob wyman

On Tue, Mar 27, 2012 at 2:06 PM, Paul E. Jones <[email-masked]>wrote:

> Bob,****
>
> ** **
>
> Is “pres:” being used in practice?  Does it refer to SIP or XMPP or other
> presence protocol?****
>
> ** **
>
> I’ll note that adding this one might incite additional concerns for
> privacy.  I assume that whatever protocol to which pres: refers (which is
> unclear to me) would handle the authorization aspects.  But, I’m left
> wondering… if one knows a person’s SIP or XMPP URI, why would one need
> pres:?****
>
> ** **
>
> Paul****
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf Of *Bob
> Wyman
> *Sent:* Tuesday, March 27, 2012 1:18 PM
> *To:* Paul E. Jones
> *Cc:* [email-masked]
>
> *Subject:* Re: [apps-discuss] Webfinger discussion****
>
> ** **
>
> Paul,****
>
> information. ****
> ** **
> bob wyman****
> ** **
> wrote:****
> Paul****
> https://www.ietf.org/mailman/listinfo/apps-discuss****
>
> ** **
>

---

From: James M Snell <[email-masked]>
Date: Tue, 27 Mar 2012 11:18:43 -0700

They are rather technical in nature and speak to the overall operation
of the protocol. I've written up a detailed version of my feedback
here [1]

[1] http://chmod777self.blogspot.com/2012/03/thoughts-on-webfinger.html

The summary version is this: I believe we can make this even simpler
without sacrificing basic operation by saying simply:

  If I want to know about user "[email-masked]", send a GET request to:
  http://example.org/.well-known/finger/{md5(acct:[email-masked])} and
  see what I get back.

The requirement to use XRD/JRD and first look up information about the
LRDD service in host-meta is quite unnecessary. Also note that the ID
is hashed in the request URI for privacy/security purposes...

We can expand on that basic idea further to say:

  If I want to know if "[email-masked]" has a "blog" and where it is located,
  I could simply send a request to:
  http://example.org/.well-known/finger/f49c533fa0f0bc7ee9cc8c88902302ba/blog

  and the server can respond with a redirect to the proper location:

  HTTP/1.1 302 Found
  Location: http://blogs.example.org/bob

The "/blog" portion of the request URI specifies a Link rel... if I
want to discover some other type of service... say, the users profile
or avatar, I simply link the different rel attribute value there..
e.g.

  http://example.org/.well-known/finger/f49c533fa0f0bc7ee9cc8c88902302ba/avatar
  http://example.org/.well-known/finger/f49c533fa0f0bc7ee9cc8c88902302ba/profile

If there are multiple links for a particular rel, the server can
respond with a 300 Multiple Options response.

The point is that requiring XRD/JRD isn't actually necessary, and
requiring the initial host metadata step isn't required also.

Requiring CORS is also isn't necessary.

Anyway, that's the basic rundown.

- James

---

From: 'Andrew Sullivan' <[email-masked]>
Date: Tue, 27 Mar 2012 15:32:54 -0400

> considerations we should note?

I wish I had something more intelligent to say than, "Is anyone [else]
worried about the aggregation of this information amd what it does to
the security profile of the aggregated things?"  Note this isn't
exactly the privacy issue, though there's that.  As nearly as I can
tell, one natural use case (or anyway, something people said) was that
you can aggregate information across services so that, for instance,
it would be easy to tell about the relationships among me@service1,
me@service2, and me@service3.  If I'm misunderstanding (this happens a
lot, note, so don't be afraid to point and laugh), please correct me.

If I understood correctly, it seems to me that disclosing something
about the relationship of these three accounts is in effect a new
disclosure, and that it offers potential for analysis (and therefore
attacks) that might not have been available given the individual
accounts alone.  But beyond that hand-wavy unease, I haven't the tools
to say anything really sensible.  Maybe there's some sort of secdir
guidance for this sort of thing?  (Note that I'm not a security guy,
and I don't play one on TV either.  This is just the sort of thing
they warned me about when I was a kid, and I think that's why I have
the heebie-jeebies about this.  Maybe I'm just superstitious.)

Thanks for putting up with the hand-waving (which will stop now),

A

-- 
Andrew Sullivan
[email-masked]

---

From: Bob Wyman <[email-masked]>
Date: Tue, 27 Mar 2012 16:16:45 -0400

> is hashed in the request URI for privacy/security purposes...
Given WebFinger as currently defined, you are probably correct in saying
that the LRDD lookup is unnecessary. The reason for this is WebFinger only
defines a single variable for use in Templates. Thus, the easiest thing to
do is to simply define a standard URI for doing WebFinger lookups. The
Template mechanism provides more generality than is useful for WebFinger as
defined.

Things could have been different -- and I think that was part of folk's
original thinking here. For instance, WebFinger might have defined a few
more Template variables or provided for a registry of template variables.
In that case, we might have seen: "Full_Name", "telephone number,"
"Student_ID_Number" and many other variables Then, there would have been a
question as to how to construct the WebFinger query URI --  (Which
variables are supported by the current server?  How should the URI be
composed?).

It would, I think, simplify matters if, as you suggest, we define a fixed
URI for WebFinger. If anyone really wants a service that can be used to map
from attributes to WebFinger acct: URIs, then they can do so in a different
specification. (i.e. This new "WebFinger Acct Lookup Service" would do
lookups from stuff like "full_name"="bob wyman" to acct:[email-masked])

One other advantage that comes from using the two-step, template-driven
approach is that it is easier to handle re-directions in some environments.
Given the current spec, I can ask example.com/... for an LRDD that might
tell me that I really should be asking webfinger.example.com for WebFinger
information instead. Certainly, the same can be handled using HTTP
redirects, however, HTTP redirects may be managed by someone other than the
person who manages the LRDDs. (i.e. Given the way host-meta works, even if
I'm running a web site on a fairly strictly controlled shared service, I
can accomplish much by simply putting a file named ".well-known/host-meta"
on my site. But, it might be much harder for me to get those who run the
shared service to define a redirect for me.)

I like the idea of passing acct: URIs as hash values. Clearly, such simple
obfuscation is relatively transparent (subject to dictionary attack),
nonetheless, it would raise the cost of interception by a reasonably useful
amount. Nonetheless, I suspect that this is the sort of thing that might
best be a SHOULD for clients while a MUST for servers.

bob wyman

> > If the other items are editorial, perhaps just direct them to me.  If
> they are items that others might want to weigh in on, then this list is the
> appropriate venue.
> >
> > Paul
> >

---

From: SM <[email-masked]>
Date: Tue, 27 Mar 2012 15:13:52 -0700

>the security profile of the aggregated things?"  Note this isn't

I'll label it as a concern.

>accounts alone.  But beyond that hand-wavy unease, I haven't the tools

Yes.

>guidance for this sort of thing?  (Note that I'm not a security guy,

That might be summed up as:

  "If one does not wish to share certain information with the world, do
   not allow that information to be accessible through Webfinger."

I suggest that the authors take a look at draft-iab-privacy-considerations-02.

Regards,
-sm

---

From: Goix Laurent Walter <[email-masked]>
Date: Wed, 28 Mar 2012 08:55:31 +0200

Hello james, all,

I could see many sort of threads going in parallel in this discussion addressing different types of concerns. I don't want to enter the "security" discussion here but rather comment on some specific technical points related to the "protocol":

- the "finger" (or lrdd) well-known endpoint could be a shortcut to consider to directly invoke the webfinger endpoint without the need for the host-meta. This skips one http transaction, although I would imagine in most cases that the host-meta xrd 1) can be cached by the invoking client, 2) can contain additional useful info (eg OExchange endpoint link).

- I am not sure about the exact value brought by the md5 hash, also considering that APIs already exist (e.g. OpenSocial) that use plain identifiers as part of the path. I cannot see much difference here wrt security that justifies this need for webfinger. In any case support for md5 hash would probably need to be declared by the server, eg using {md5uri} instead of {uri} in the lrdd template.

- regarding the shortcuts to link rel types this is becoming more a protocol for accessing user info rather than discovery. i can see this as a direct/standard API/URL to access user information (e.g. avatar, profile-page). This misses the "type" (content-type) which may vary within a single rel (although this could be addressed by Accept: headers) and is significantly different from the original scope of webfinger for discovery only (I could imagine you could further extend your proposal to perform CRUD operations on the single rels, which tends to become close to opensocial apis).
The information contained in the xrd/jrd can in fact easily be cached altogether for subsequent use and not for immediate consumption of all rel types. I would assume this is not more complex than parsing the various Link: headers in the responses.
But i can understand there may be some new use case where a user is only interested in 1-2 rels for instant consumption, and some solution may be investigated for this.

- regarding OAuth it can be valuable in case webfinger is queried directly by applications. However in most current usages (ostatus, diaspora, etc) the webfinger discovery process is performed by a server of another domain, thus limiting the possible usage of oauth in that case.

walter

-----Messaggio originale-----
Da: [email-masked] [mailto:[email-masked]] Per conto di James M Snell
Inviato: martedì 27 marzo 2012 20.19
A: Paul E. Jones
Cc: [email-masked]
Oggetto: Re: [apps-discuss] Webfinger discussion

  HTTP/1.1 302 Found

- James

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.

---

From: John C Klensin <[email-masked]>
Date: Wed, 28 Mar 2012 05:42:33 -0400

--On Tuesday, March 27, 2012 15:32 -0400 'Andrew Sullivan'
<[email-masked]> wrote:

>> We'll add text along those lines to the next draft.  Any
>> other security considerations we should note?
> 
> I wish I had something more intelligent to say than, "Is
> anyone [else] worried about the aggregation of this
> information amd what it does to the security profile of the
> aggregated things?"  Note this isn't exactly the privacy
> issue, though there's that. 

Short answer: yes.

Slightly longer answer: While most of today's privacy
discussions correctly focus on such questions as "why do you
need to know that", "why should I tell you", and "if I do tell
you, what control do I have over your telling others", many of
the really hard questions lie in the observation that the more
dimensions of information I know about you (or about your
membership in various groups and categories) the more I identify
you and predict your behavior in statistically-interesting ways.
Now combining information associated with me@service1,
me@service2, and me@service3 doesn't inherently create any extra
risk unless you have (deliberately or accidentally) associated
different information with those identities s.t. the information
content in their union is significantly larger than the
information content in their intersection.   If that
relationship holds, you are exposed to a new family of
unintended disclosures, some of it based on statistical models
of the behavior of populations that share a large enough number
of attribute categories with you.

I have no idea how we go about sorting it out, but I agree that
we need to be clear about the possibility and risks.

   john

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 28 Mar 2012 13:28:00 +0200

I reproach myself for having missed the Internet Society Panel on OpenID and
OAuth yesterday morning.  I'll try and find the recording.  Meanwhile, does
someone know if there is a way to get an email address from an id?

>   http://example.org/.well-known/finger/{md5(acct:[email-masked])} and

That implies the address is known.  Couldn't one use just

   http://example.org/.well-known/finger/{opaque-token}

and, possibly,

   http://example.org/.well-known/finger/{opaque-token}/email-addr?

The idea is that the relevant user, well, Bob in this case, can be logged in
more or less at the same time as he triggered an automatic query of that url.
For example, he might be buying a DVD at Amazon's.  Bob's server might let
him choose whether to supply his plain email address or any variant thereof,
possibly offering to update Sieve scripts while it's at it.

Is perhaps SCIM, or whatever other framework, nearer to such kind of use
cases?  It could be used as a better double-opt-in...  (Yes, I'm the one who
asked what's the difference between Webfinger and SCIM on Monday, and I'm
apparently still unclear on that.)

---

From: Bob Wyman <[email-masked]>
Date: Wed, 28 Mar 2012 11:00:29 -0400

On Wed, Mar 28, 2012 at 2:55 AM, Goix Laurent Walter <
[email-masked]> wrote:
> more a protocol for accessing user info rather than discovery
Forgive me if I'm being dense, but could you expand a bit on the difference
between "accessing user info" and "discovery?"

> - regarding OAuth it can be valuable in case webfinger is queried
directly by applications.
Certainly, OAuth would be useful when combined with WebFinger. I would like
to be able to have the equivalent of ACLs that would be used to vary the
WebFinger responses based on who authenticates. For instance, in mapping
from acct: URI to mailto:, I might want one group of people to receive one
mailto: and another group to see a different value or no value.

I think we need to also consider that there are alternatives to existing
practice of providing "values" directly in the WebFinger XRD/JRDs. An
alternative would be to provide  pointers to other services that can
provide the desired answers. (i.e. Adding yet another level of
indirection...) in other words, rather than providing the mailto: address
that corresponds to a particular acct: URI, the XRD/JRD could point to a
service which uses OAuth and that can be queried to provide whichever of
several mailto: addresses that are appropriate -- depending on the results
of authentication.

bob wyman

On Wed, Mar 28, 2012 at 2:55 AM, Goix Laurent Walter <
[email-masked]> wrote:

> Hello james, all,
>
> I could see many sort of threads going in parallel in this discussion
> addressing different types of concerns. I don't want to enter the
> "security" discussion here but rather comment on some specific technical
> points related to the "protocol":
>
> - the "finger" (or lrdd) well-known endpoint could be a shortcut to
> consider to directly invoke the webfinger endpoint without the need for the
> host-meta. This skips one http transaction, although I would imagine in
> most cases that the host-meta xrd 1) can be cached by the invoking client,
> 2) can contain additional useful info (eg OExchange endpoint link).
>
> - I am not sure about the exact value brought by the md5 hash, also
> considering that APIs already exist (e.g. OpenSocial) that use plain
> identifiers as part of the path. I cannot see much difference here wrt
> security that justifies this need for webfinger. In any case support for
> md5 hash would probably need to be declared by the server, eg using
> {md5uri} instead of {uri} in the lrdd template.
>
> - regarding the shortcuts to link rel types this is becoming more a
> protocol for accessing user info rather than discovery. i can see this as a
> direct/standard API/URL to access user information (e.g. avatar,
> profile-page). This misses the "type" (content-type) which may vary within
> a single rel (although this could be addressed by Accept: headers) and is
> significantly different from the original scope of webfinger for discovery
> only (I could imagine you could further extend your proposal to perform
> CRUD operations on the single rels, which tends to become close to
> opensocial apis).
> The information contained in the xrd/jrd can in fact easily be cached
> altogether for subsequent use and not for immediate consumption of all rel
> types. I would assume this is not more complex than parsing the various
> Link: headers in the responses.
> But i can understand there may be some new use case where a user is only
> interested in 1-2 rels for instant consumption, and some solution may be
> investigated for this.
>
> - regarding OAuth it can be valuable in case webfinger is queried directly
> by applications. However in most current usages (ostatus, diaspora, etc)
> the webfinger discovery process is performed by a server of another domain,
> thus limiting the possible usage of oauth in that case.
>
> walter
>
> 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.
>

---

From: Goix Laurent Walter <[email-masked]>
Date: Wed, 28 Mar 2012 17:17:08 +0200

> more a protocol for accessing user info rather than discovery
Forgive me if I'm being dense, but could you expand a bit on the difference between "accessing user info" and "discovery?"

[walter] by "accessing user info" I mean directly accessing actual information about a user (my profile details, activity stream, etc). what I mean by "discovery" is to retrieve a pointer to a specific information. Webfinger is aimed at becoming a discovery protocol. There are plenty of other protocol/apis/interfaces for accessing information that could be "discovered" through webfinger and then use very different/specific communications means. I hope I clarified my point here.

> - regarding OAuth it can be valuable in case webfinger is queried directly by applications.
Certainly, OAuth would be useful when combined with WebFinger. I would like to be able to have the equivalent of ACLs that would be used to vary the WebFinger responses based on who authenticates. For instance, in mapping from acct: URI to mailto:, I might want one group of people to receive one mailto: and another group to see a different value or no value.

I think we need to also consider that there are alternatives to existing practice of providing "values" directly in the WebFinger XRD/JRDs. An alternative would be to provide  pointers to other services that can provide the desired answers. (i.e. Adding yet another level of indirection...) in other words, rather than providing the mailto: address that corresponds to a particular acct: URI, the XRD/JRD could point to a service which uses OAuth and that can be queried to provide whichever of several mailto: addresses that are appropriate -- depending on the results of authentication.

[walter] i have not seen webfinger usages where "values" are directly provided and would be very careful with it (I would be glad to see if there are already such usages deployed). Imho the entire purpose of webfinger is to discover "pointers" to information, not the information itself. This allows any security mechanism to be applied on those specific endpoints (+ on webfinger endpoint itself) to control access to the actual information (profile, activities, etc).
Again, oauth could work for users/invocations within a single social network/domain, but I could hardly imagine it working for server-to-server transactions (eg a user from one SN acts on his server's webpage to follow a user on another SN). Or do you have other scenarios in mind with oauth?
The only direct information I could easily imagine in a xrd is another "acct" uri in case of portability. Other personal uris (eg im:, mailto:, etc) should be handled with care and imo not included in the xrd but rather in a profile description (hcard, foaf, etc), whose link is provided in the xrd (so that a more precise acl can be applied when someone wants to access it)

walter

bob wyman
On Wed, Mar 28, 2012 at 2:55 AM, Goix Laurent Walter <[email-masked]<mailto:[email-masked]>> wrote:
Hello james, all,

walter

-----Messaggio originale-----
Da: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] Per conto di James M Snell
Inviato: martedì 27 marzo 2012 20.19
A: Paul E. Jones
Cc: [email-masked]<mailto:[email-masked]>
Oggetto: Re: [apps-discuss] Webfinger discussion

 If I want to know about user "[email-masked]<mailto:[email-masked]>", send a GET request to:
 http://example.org/.well-known/finger/{md5(acct:[email-masked])}<http://example.org/.well-known/finger/%7bmd5(acct:[email-masked])%7d> and
 see what I get back.

 If I want to know if "[email-masked]<mailto:[email-masked]>" has a "blog" and where it is located,
 I could simply send a request to:
 http://example.org/.well-known/finger/f49c533fa0f0bc7ee9cc8c88902302ba/blog

 HTTP/1.1 302 Found

- James

On Tue, Mar 27, 2012 at 9:57 AM, Paul E. Jones <[email-masked]<mailto:[email-masked]>> wrote:
>> From: James M Snell [mailto:[email-masked]<mailto:[email-masked]>]
>> Cc: Andrew Sullivan; [email-masked]<mailto:[email-masked]>
>> On Tue, Mar 27, 2012 at 9:15 AM, Paul E. Jones <[email-masked]<mailto:[email-masked]>>
>> wrote:
>> >> From: [email-masked]<mailto:[email-masked]>
>> >> [mailto:[email-masked]<mailto:[email-masked]>]
>> >> To: [email-masked]<mailto:[email-masked]>
>> >> [email-masked]<mailto:[email-masked]>
>> >> [email-masked]<mailto:[email-masked]>
>> > [email-masked]<mailto:[email-masked]>
[email-masked]<mailto:[email-masked]>

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

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

---

From: Bob Wyman <[email-masked]>
Date: Wed, 28 Mar 2012 14:06:34 -0400

On Wed, Mar 28, 2012 at 11:17 AM, Goix Laurent Walter <
[email-masked]> wrote:

> > i have not seen webfinger usages where “values” are directly provided
What is a "pointer" for you may be a "value" for me. Consider the case
where the URL of my blog is identified. Is that a pointer, a value or both
at the same time? It seems to me that in these cases, the distinction
between "pointer" and "value" is not inherent to the data provided but
rather is found in how the data is used.

bob wyman

On Wed, Mar 28, 2012 at 11:17 AM, Goix Laurent Walter <
[email-masked]> wrote:

> Forgive me if I'm being dense, but could you expand a bit on the
> difference between "accessing user info" and "discovery?"****
>
> ** **
>
> [walter] by "accessing user info” I mean directly accessing actual
> information about a user (my profile details, activity stream, etc). what I
> mean by “discovery” is to retrieve a pointer to a specific information.
> Webfinger is aimed at becoming a discovery protocol. There are plenty of
> other protocol/apis/interfaces for accessing information that could be
> “discovered” through webfinger and then use very different/specific
> communications means. I hope I clarified my point here.****
>
> ** **
>
> directly by applications.****
>
> Certainly, OAuth would be useful when combined with WebFinger. I would
> like to be able to have the equivalent of ACLs that would be used to vary
> the WebFinger responses based on who authenticates. For instance, in
> mapping from acct: URI to mailto:, I might want one group of people to
> receive one mailto: and another group to see a different value or no
> value.****
>
> ** **
>
> several mailto: addresses that are appropriate -- depending on the
> results of authentication.****
>
> ** **
>
> [walter] i have not seen webfinger usages where “values” are directly
> provided and would be very careful with it (I would be glad to see if there
> are already such usages deployed). Imho the entire purpose of webfinger is
> to discover “pointers” to information, not the information itself. This
> allows any security mechanism to be applied on those specific endpoints (+
> on webfinger endpoint itself) to control access to the actual information
> (profile, activities, etc). ****
>
> Again, oauth could work for users/invocations within a single social
> network/domain, but I could hardly imagine it working for server-to-server
> transactions (eg a user from one SN acts on his server’s webpage to follow
> a user on another SN). Or do you have other scenarios in mind with oauth?*
> ***
>
> The only direct information I could easily imagine in a xrd is another
> “acct” uri in case of portability. Other personal uris (eg im:, mailto:,
> etc) should be handled with care and imo not included in the xrd but rather
> in a profile description (hcard, foaf, etc), whose link is provided in the
> xrd (so that a more precise acl can be applied when someone wants to access
> it)****
>
> ** **
>
> walter****
>
> ** **
>
> bob wyman****
>
> [email-masked]> wrote:****
>
> Hello james, all,
>
> Inviato: martedì 27 marzo 2012 20.19****
>
> A: Paul E. Jones
> Cc: [email-masked]****
>
> Oggetto: Re: [apps-discuss] Webfinger discussion****
>
>
> advise the sender by return e-mail, Thanks.****
>
>
>    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: Wed, 28 Mar 2012 17:07:24 -0400

Bob,

Given I'm not sure how to really use these off-hand, I'd prefer we did not
put them into examples.  It would be reasonable to define an "im" link
relation, though.  Then the href can refer to something concrete like
xmpp:[email-masked].

Paul

From: [email-masked] [mailto:[email-masked]] On Behalf Of Bob Wyman
Sent: Tuesday, March 27, 2012 2:13 PM
To: Paul E. Jones
Cc: [email-masked]
Subject: Re: [apps-discuss] Webfinger discussion

bob wyman

On Tue, Mar 27, 2012 at 2:06 PM, Paul E. Jones <[email-masked]>
wrote:

Bob,

Paul

Paul,

bob wyman

James,

Paul

---

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 28 Mar 2012 17:09:44 -0400

That said. vcard defines addresses like IM.  We ought not duplicate
information, but I'm not sure where to draw the line.

Paul

From: Paul E. Jones [mailto:[email-masked]] 
Sent: Wednesday, March 28, 2012 5:07 PM
To: 'Bob Wyman'
Cc: [email-masked]'
Subject: RE: [apps-discuss] Webfinger discussion

Bob,

Paul

bob wyman

Bob,

Paul

Paul,

bob wyman

James,

Paul

---

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 28 Mar 2012 17:49:34 -0400

James,

I really like this idea.  It makes an attempt to short-cut some of the procedures, very much in line with what the "resource" parameter does in Section 4.2 of the Webfinger draft.  I don't have a particular love for the using MD5, preferring something like this:

GET /.well-known/webfinger?resource=acct%3Abob%40example.com&rel=blog HTTP/1.1

Since any reply might have multiple links, then the 204 reply including links would likely be necessary.  Using 302 would not be right, since that has a different meaning: the client would go to Location trying to resolve the original request.  A 204 with any number of Link headers would be good.

Using the resource parameter means we make a query and get a JRD or XRD document.  What we cannot do is query for one specific type of content.

Changing Webfinger so drastically is a challenge since Webfinger builds on RFC 6415. But, I do like the idea of querying for a very specific value like this:

GET /.well-known/host-meta.json?resource=acct%3Abob%40example.com&rel=blog HTTP/1.1

Perhaps this might return a reply like this:

HTTP/1.1 204 No Content
Link: <http://blogs.example.org/bob/>; rel="blog"

A challenge with this, though, is that it means the application has to deal with two different formats.  Either JRD/XRD or an HTTP header with Links.

We could introduce this and make it mandatory if the resource parameter is supported.  However, would it make the client-side code simpler?  Support for the "resource" parameter is already optional.  (We could make it mandatory, but I did get pushback on that.)

Paul

> Sent: Tuesday, March 27, 2012 2:19 PM
> To: Paul E. Jones
> They are rather technical in nature and speak to the overall operation of
> the protocol. I've written up a detailed version of my feedback here [1]
> 
> LRDD service in host-meta is quite unnecessary. Also note that the ID is
> hashed in the request URI for privacy/security purposes...
> 
>   http://example.org/.well-
> known/finger/f49c533fa0f0bc7ee9cc8c88902302ba/blog
> 
> The "/blog" portion of the request URI specifies a Link rel... if I want
> to discover some other type of service... say, the users profile or
> avatar, I simply link the different rel attribute value there..
> e.g.
> 
>   http://example.org/.well-
> known/finger/f49c533fa0f0bc7ee9cc8c88902302ba/avatar
>   http://example.org/.well-
> known/finger/f49c533fa0f0bc7ee9cc8c88902302ba/profile
> 
> If there are multiple links for a particular rel, the server can respond
> with a 300 Multiple Options response.
> 
> they are items that others might want to weigh in on, then this list is
> the appropriate venue.
> >
> > Paul
> >
> >> leaks of this nature with WebFinger that did not really exist with
> >> the original Finger protocol. OAuth 2, for instance. A WebFinger
> >> endpoint could choose to serve up only the most basic static
> >> information to unauthenticated requesters, but then provide a means
> >> for a requester to authenticate and request permission from the
> >> target user or provider to acquire additional information as part of
> the response.
> >>
> >> On a side note to Paul: I did have some additional general comments
> >> on the WebFinger spec itself, I wanted to ask where such comments
> >> would be best directed for discussion.
> >>
> >> - James
> >>
> >> On Tue, Mar 27, 2012 at 9:15 AM, Paul E. Jones
> >> <[email-masked]>
> >> wrote:
> >> > I agree it would be useful to add text about sharing information
> >> > that might be dynamic in nature (e.g., current user location).
> >> >
> >> >> > un-recommended!). If people did, in fact, use WebFinger to
> >> >> > record such stuff, the concerns you mentioned would be relevant.
> >> >> > Thus, it might make sense for the Security Considerations
> >> >> Right, that's most of what I was trying to say.  I do have a
> >> >> concern that collecting a bunch of different information about a
> >> >> given person and linking it together in a single, easy to access
> >> >> repository has some potential security side effects (not just
> >> >> privacy ones, but those too, of
> >> >> I suppose one could argue that facebook's (or pick your poison)
> >> >> user population shows nobody cares about that, but I think it
> >> >> would still be good to have some observations about those effects.
> >> >>
> >> >> Best,
> >> >>
> >> >> A
> >> >>
> >> >> --
> >> >> Andrew Sullivan
> >> >> [email-masked]

---

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 28 Mar 2012 18:13:37 -0400

Get an email address from what ID?  A Webfinger "acct" URI?

Paul

> On Behalf Of Alessandro Vesely
> Sent: Wednesday, March 28, 2012 7:28 AM
> Subject: [apps-discuss] What auth server supplies email addresses? Was
> webfinger discussion
> 
> I reproach myself for having missed the Internet Society Panel on OpenID
> and OAuth yesterday morning.  I'll try and find the recording.  Meanwhile,
> does someone know if there is a way to get an email address from an id?
> 
> The idea is that the relevant user, well, Bob in this case, can be logged
> in more or less at the same time as he triggered an automatic query of
> that url.
> him choose whether to supply his plain email address or any variant
> thereof, possibly offering to update Sieve scripts while it's at it.
> 
> cases?  It could be used as a better double-opt-in...  (Yes, I'm the one
> who asked what's the difference between Webfinger and SCIM on Monday, and
> I'm apparently still unclear on that.)
>

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 29 Mar 2012 13:57:17 +0200

> Get an email address from what ID?  A Webfinger "acct" URI?

In general, the opaque token would be kind-of-claim @ claim-provider

---

From: Eran Hammer <[email-masked]>
Date: Thu, 29 Mar 2012 09:12:11 -0700

RFC 6415 (host-meta) was the end of a long evolution of discovery ideas. I would strongly caution against throwing it away and starting from scratch given the amount of experience and balance that was put into it. There are easy things we can do to make it easier to use and more efficient, without losing its main architectural benefits (caching, simplicity, ease of deployment, efficiency in templates, security, flexible schema, etc.).

In the past I've proposed adding query parameters to the endpoint to allow for direct retrieval of information without having to parse the document. I have also suggested moving away from XRD to JRD as the primary format. BTW, XRD has nothing to do with XRI and all to do with HTTP Link relations - so people should get over their bias and hate for XRI and give this work the benefit of the doubt.

The key to this work has always been adoption. These protocols are useless without large companies (primarily email providers as currently proposed) supporting it, which was a significant driving force in shaping the protocol based on what these companies were able and willing to deploy.

For example, Yahoo was a strong supporter of the template mechanism because it enable them to deploy a single static file that provided information about all their users for the purpose of address book discovery.

EH

> From: [email-masked] [mailto:apps-discuss-
> [email-masked]] On Behalf Of Paul E. Jones
> Sent: Wednesday, March 28, 2012 2:50 PM
> To: 'James M Snell'
> I really like this idea.  It makes an attempt to short-cut some of the
> procedures, very much in line with what the "resource" parameter does in
> Section 4.2 of the Webfinger draft.  I don't have a particular love for the using
> MD5, preferring something like this:
> 
> GET /.well-
> known/webfinger?resource=acct%3Abob%40example.com&rel=blog
> HTTP/1.1
> 
> Since any reply might have multiple links, then the 204 reply including links
> would likely be necessary.  Using 302 would not be right, since that has a
> different meaning: the client would go to Location trying to resolve the
> original request.  A 204 with any number of Link headers would be good.
> 
> Using the resource parameter means we make a query and get a JRD or XRD
> document.  What we cannot do is query for one specific type of content.
> 
> Changing Webfinger so drastically is a challenge since Webfinger builds on
> RFC 6415. But, I do like the idea of querying for a very specific value like this:
> 
> GET /.well-known/host-
> meta.json?resource=acct%3Abob%40example.com&rel=blog HTTP/1.1
> 
> A challenge with this, though, is that it means the application has to deal with
> two different formats.  Either JRD/XRD or an HTTP header with Links.
> 
> We could introduce this and make it mandatory if the resource parameter is
> supported.  However, would it make the client-side code simpler?  Support
> for the "resource" parameter is already optional.  (We could make it
> mandatory, but I did get pushback on that.)
> 
> Paul
> 
> > [1]
> > http://chmod777self.blogspot.com/2012/03/thoughts-on-webfinger.html
> >
> > they are items that others might want to weigh in on, then this list
> > is the appropriate venue.
> > >
> > > Paul
> > >
> > >> To be fair, there are ways of dealing with the potential for
> > >> security leaks of this nature with WebFinger that did not really
> > >> exist with the original Finger protocol. OAuth 2, for instance. A
> > >> WebFinger endpoint could choose to serve up only the most basic
> > >> static information to unauthenticated requesters, but then provide
> > >> a means for a requester to authenticate and request permission from
> > >> the target user or provider to acquire additional information as
> > >> part of
> > the response.
> > >>
> > >> >> > section to suggest that one should think carefully before
> > >> >> > using WebFinger to provide such dynamic
> > >> >> information.
> > >> >>

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 30 Mar 2012 11:30:47 +0200

On Fri 30/Mar/2012 08:51:12 +0200 Paul E. Jones wrote:

> I still do not understand :-(
> 
> Can you elaborate for me a bit more?

I may be conflating webfinger, openid, browserid, webid, and some other
protocols of that sort.  At any rate, it was said that a functionality
relevant to some of those is to certify a generic claim, for example whether
someone is legally allowed to drive a lorry in France.  The user would
indicate the kind-of-claim (driving license) and a trusted certifier (the
French motoring authority) without revealing his/her identity.  The relaying
party would then let the user login at the certifier's site in order to
eventually obtain the certificate.

By the same logic, given that example.com should be universally trusted for
email addresses that end with "@example.com", its server would be able to
provide a certified, anonymous email address ([email-masked]) to a shop,
on behalf of a customer who wishes to protect his/her main address.

>> Sent: Thursday, March 29, 2012 7:57 AM
>> Subject: Re: [apps-discuss] What auth server supplies email addresses? Was
>> webfinger discussion
>>

---

From: "Paul E. Jones" <[email-masked]>
Date: Fri, 30 Mar 2012 14:03:24 -0400

What you describe sounds a bit like JWT:
http://openid.net/specs/draft-jones-json-web-token-07.html

Or, it might be OpenID Connect, which uses JWT.  (What you describe is not
in OpenID 2.0.)

Paul

> From: Alessandro Vesely [mailto:[email-masked]]
> Sent: Friday, March 30, 2012 5:31 AM
> To: Paul E. Jones
> relevant to some of those is to certify a generic claim, for example
> whether someone is legally allowed to drive a lorry in France.  The user
> would indicate the kind-of-claim (driving license) and a trusted certifier
> (the French motoring authority) without revealing his/her identity.  The
> relaying party would then let the user login at the certifier's site in
> order to eventually obtain the certificate.
> 
> By the same logic, given that example.com should be universally trusted
> for email addresses that end with "@example.com", its server would be able
> to provide a certified, anonymous email address ([email-masked]) to a
> shop, on behalf of a customer who wishes to protect his/her main address.
> 
> >> Subject: Re: [apps-discuss] What auth server supplies email
> >> addresses? Was webfinger discussion
> >>