Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D68A521E819B for ; Wed, 28 Mar 2012 11:06:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.694 X-Spam-Level: X-Spam-Status: No, score=-2.694 tagged_above=-999 required=5 tests=[AWL=0.282, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y5K10wNf42vH for ; Wed, 28 Mar 2012 11:06:35 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 644E021E81C2 for ; Wed, 28 Mar 2012 11:06:35 -0700 (PDT) Received: by qaea16 with SMTP id a16so991157qae.10 for ; Wed, 28 Mar 2012 11:06:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=hNyAp3qWrZbXiTRYWsGd/UZdDeseCtFwMiSxV2r4LLY=; b=q/YY4Ld8RqeKR3Wut7gzQGdtDZlTSIF9M/YhbvyfpI+EQW+IKvRonUby1vZqsZgiGT r1AQJ4rFTohCGF8zt5ejIBobrsxiMkyogQc5lyvE2LLUV1fkjC0Rvud8jqEfxXw2nZqG 9XcYeeJLkAIbtpUDplBCfgOIhrUk2HN/8NN3jdIn2NH34TBsrae/HPnXcGCOWiat4ffN VVuJ/nfya4xYCfqNUE6J8s1TOFF/ZSfZzVmYANqj5RcNktBV9YsXJCMBanWZytwXbg8L R2ZJLlX2c8dNhx6L6miINVi0beeHdOmoOCd6smW2KodH4CNXQ7YsxZh9T4rVvzzQndXF sLcA== MIME-Version: 1.0 Received: by 10.224.210.129 with SMTP id gk1mr39187486qab.85.1332957994659; Wed, 28 Mar 2012 11:06:34 -0700 (PDT) Sender: bobwyman@gmail.com Received: by 10.229.157.16 with HTTP; Wed, 28 Mar 2012 11:06:34 -0700 (PDT) In-Reply-To: References: <053201cd0b5d$c08c80f0$41a582d0$@packetizer.com> <20120326150556.GC3557@mail.yitter.info> <20120327084709.GB11491@mail.yitter.info> <00ac01cd0c34$cfc96f10$6f5c4d30$@packetizer.com> <00d201cd0c3a$b3672410$1a356c30$@packetizer.com> Date: Wed, 28 Mar 2012 14:06:34 -0400 X-Google-Sender-Auth: cbhADbm3H3VYLH2Lc5nXeuglBtE Message-ID: From: Bob Wyman To: Goix Laurent Walter Content-Type: multipart/related; boundary=20cf300faca1c5af2304bc517712 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] R: Webfinger discussion X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 18:06:38 -0000 --20cf300faca1c5af2304bc517712 Content-Type: multipart/alternative; boundary=20cf300faca1c5af2104bc517711 --20cf300faca1c5af2104bc517711 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Wed, Mar 28, 2012 at 11:17 AM, Goix Laurent Walter < laurentwalter.goix@telecomitalia.it> wrote: > > i have not seen webfinger usages where =93values=94 are directly provid= ed 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 < laurentwalter.goix@telecomitalia.it> wrote: > On Wed, Mar 28, 2012 at 2:55 AM, Goix Laurent Walter < > laurentwalter.goix@telecomitalia.it> 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?"**** > > ** ** > > [walter] by "accessing user info=94 I mean directly accessing actual > information about a user (my profile details, activity stream, etc). what= I > mean by =93discovery=94 is to retrieve a pointer to a specific informatio= n. > Webfinger is aimed at becoming a discovery protocol. There are plenty of > other protocol/apis/interfaces for accessing information that could be > =93discovered=94 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 =93values=94 are directly > provided and would be very careful with it (I would be glad to see if the= re > are already such usages deployed). Imho the entire purpose of webfinger i= s > to discover =93pointers=94 to information, not the information itself. Th= is > 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-serve= r > transactions (eg a user from one SN acts on his server=92s webpage to fol= low > 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 > =93acct=94 uri in case of portability. Other personal uris (eg im:, mailt= o:, > etc) should be handled with care and imo not included in the xrd but rath= er > in a profile description (hcard, foaf, etc), whose link is provided in th= e > xrd (so that a more precise acl can be applied when someone wants to acce= ss > it)**** > > ** ** > > walter**** > > ** ** > > bob wyman**** > > On Wed, Mar 28, 2012 at 2:55 AM, Goix Laurent Walter < > laurentwalter.goix@telecomitalia.it> 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 t= he > 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 withi= n > a single rel (although this could be addressed by Accept: headers) and is > significantly different from the original scope of webfinger for discover= y > 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 re= l > 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 directl= y > by applications. However in most current usages (ostatus, diaspora, etc) > the webfinger discovery process is performed by a server of another domai= n, > thus limiting the possible usage of oauth in that case. > > walter > > -----Messaggio originale----- > Da: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] > Per conto di James M Snell > Inviato: marted=EC 27 marzo 2012 20.19**** > > A: Paul E. Jones > Cc: apps-discuss@ietf.org**** > > Oggetto: Re: [apps-discuss] Webfinger discussion**** > > > 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 "bob@example.org", send a GET request to: > http://example.org/.well-known/finger/{md5(acct:bob@example.org)} 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 "bob@example.org" has a "blog" and where it is > located, > I could simply send a request to: > > http://example.org/.well-known/finger/f49c533fa0f0bc7ee9cc8c88902302ba/bl= og > > 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/av= atar > > http://example.org/.well-known/finger/f49c533fa0f0bc7ee9cc8c88902302ba/pr= ofile > > 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 > > On Tue, Mar 27, 2012 at 9:57 AM, Paul E. Jones > 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 t= he > appropriate venue. > > > > Paul > > > >> -----Original Message----- > >> From: James M Snell [mailto:jasnell@gmail.com] > >> Sent: Tuesday, March 27, 2012 12:39 PM > >> To: Paul E. Jones > >> Cc: Andrew Sullivan; apps-discuss@ietf.org > >> Subject: Re: [apps-discuss] Webfinger discussion > >> > >> 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 t= o > >> authenticate and request permission from the target user or provider t= o > >> 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 be= st > >> directed for discussion. > >> > >> - James > >> > >> On Tue, Mar 27, 2012 at 9:15 AM, Paul E. Jones > >> wrote: > >> > I agree it would be useful to add text about sharing information tha= t > >> > 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: apps-discuss-bounces@ietf.org > >> >> [mailto:apps-discuss-bounces@ietf.org] > >> >> On Behalf Of Andrew Sullivan > >> >> Sent: Tuesday, March 27, 2012 4:47 AM > >> >> To: apps-discuss@ietf.org > >> >> Subject: Re: [apps-discuss] Webfinger discussion > >> >> > >> >> On Mon, Mar 26, 2012 at 02:31:30PM -0400, Bob Wyman wrote: > >> >> > >> >> > un-recommended!). If people did, in fact, use WebFinger to record > >> >> > such stuff, the concerns you mentioned would be relevant. Thus, i= t > >> >> > might make sense for the Security Considerations section to sugge= st > >> >> > 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 concer= n > >> >> that collecting a bunch of different information about a given pers= on > >> >> 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) use= r > >> >> population shows nobody cares about that, but I think it would stil= l > >> >> be good to have some observations about those effects. > >> >> > >> >> Best, > >> >> > >> >> A > >> >> > >> >> -- > >> >> Andrew Sullivan > >> >> ajs@anvilwalrusden.com > >> >> _______________________________________________ > >> >> apps-discuss mailing list > >> >> apps-discuss@ietf.org > >> >> https://www.ietf.org/mailman/listinfo/apps-discuss > >> > > >> > _______________________________________________ > >> > apps-discuss mailing list > >> > apps-discuss@ietf.org > >> > https://www.ietf.org/mailman/listinfo/apps-discuss > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > 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. Qualo= ra > abbiate ricevuto questo documento per errore siete cortesemente pregati d= i > darne immediata comunicazione al mittente e di provvedere alla sua > distruzione, Grazie. > > This e-mail and any attachments is confidential and may contain privilege= d > 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.**** > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > 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 an= d > advise the sender by return e-mail, Thanks.* > *[image: rispetta l'ambiente]Rispetta l'ambiente. Non stampare questa > mail se non =E8 necessario.* > > --20cf300faca1c5af2104bc517711 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
On Wed, Mar 28, 2012 at 11:17 AM, Goix Laurent Walter=A0<laurentwalte= r.goix@telecomitalia.it>=A0wrote:
>=A0i have not seen webfinger usages = where =93values=94 are directly provided=A0
What is a "pointer" for you may be a "value" for me. Co= nsider 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 d= istinction between "pointer" and "value" is not inheren= t 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 <laurentwalter.goix@telecomitalia.it> wrote:

On Wed, Mar 28, 2012 at 2:55 AM= , Goix Laurent Walter=A0<laurentwalter.goix@te= lecomitalia.it>=A0wrote:
>=A0more a protocol for accessing user info rather than discovery
Forgive me if I'm being dense, but could you expand a bit on the differ= ence between "accessing user info" and "discovery?"<= /u>

=A0=

[wal= ter] by "accessing user info=94 I mean directly accessing actual infor= mation about a user (my profile details, activity stream, etc). what I mean by =93discovery=94 is to retrieve a pointer to a specific informati= on. Webfinger is aimed at becoming a discovery protocol. There are plenty o= f other protocol/apis/interfaces for accessing information that could be = =93discovered=94 through webfinger and then use very different/specific communications means. I hope I clarified my po= int here.

=A0

>=A0- 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 woul= d be used to vary the WebFinger responses based on who authenticates. For i= nstance, in mapping from acct: URI to mailto:, I might want one group of people to receive one mailto: and an= other group to see a different value or no value.

=A0

I think we need to also consider that there are alte= rnatives to existing practice of providing "values" directly in t= he WebFinger XRD/JRDs. An alternative would be to provide =A0pointers to ot= her services that can provide the desired answers. (i.e. Adding yet another level of indirection...) in other words, rather t= han providing the mailto: address that corresponds to a particular acct: UR= I, the XRD/JRD could point to a service which uses OAuth and that can be qu= eried to provide whichever of several mailto: addresses that are appropriate -- depending on the results of auth= entication.

=A0<= /p>

[wal= ter] i have not seen webfinger usages where =93values=94 are directly provi= ded 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 =93pointers=94 to information, not the information itself. Thi= s 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, oau= th 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=92s webpage to foll= ow a user on another SN). Or do you have other scenarios in mind with oauth= ?

The only d= irect information I could easily imagine in a xrd is another =93acct=94 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 rathe= r in a profile description (hcard, foaf, etc), whose link is provided in th= e xrd (so that a more precise acl can be applied when someone wants to acce= ss it)

=A0=

walter<= /u>

=A0

bob wyman

On Wed, Mar 28, 2012 at 2:55 AM, Goix Laurent Walter= <laurentwalter.goix@telecomitalia.it> wrote:

Hello james, all,

I could see many sort of threads going in parallel in this discussion addre= ssing different types of concerns. I don't want to enter the "secu= rity" discussion here but rather comment on some specific technical po= ints 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 (e= g OExchange endpoint link).

- I am not sure about the exact value brought by the md5 hash, also conside= ring that APIs already exist (e.g. OpenSocial) that use plain identifiers a= s part of the path. I cannot see much difference here wrt security that jus= tifies 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 protoco= l 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). T= his misses the "type" (content-type) which may vary within a single rel (although this could be addressed by Ac= cept: headers) and is significantly different from the original scope of we= bfinger for discovery only (I could imagine you could further extend your p= roposal 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 altog= ether 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: he= aders in the responses.
But i can understand there may be some new use case where a user is only in= terested in 1-2 rels for instant consumption, and some solution may be inve= stigated for this.

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

walter

-----Messaggio originale-----
Da: apps= -discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] Per conto = di James M Snell
Inviato: marted=EC 27 marzo 2012 20.19

A: Paul E. Jones
Cc: apps-discuss= @ietf.org

Oggetto: Re: [apps-discuss] Webfinger discussion<= /u>


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:

=A0If I want to know about user "bob@example.org", send a GET request to:
=A0http://example.org/.well-known/finger/{md5(acct= :bob@example.org)} and
=A0see 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:

=A0If I want to know if "bob@example.org" has a "blog" and where it is lo= cated,
=A0I could simply send a request to:
=A0http://example.org/.well-known/finger/f49= c533fa0f0bc7ee9cc8c88902302ba/blog

=A0and the server can respond with a redirect to the proper location:

=A0HTTP/1.1 302 Found
=A0Location: htt= p://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.

=A0http://example.org/.well-known/finger/f= 49c533fa0f0bc7ee9cc8c88902302ba/avatar
=A0http://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

On Tue, Mar 27, 2012 at 9:57 AM, Paul E. Jones <paulej@packetizer.com> wrote:
> James,
>
> If the other items are editorial, perhaps just direct them to me. =A0I= f they are items that others might want to weigh in on, then this list is t= he appropriate venue.
>
> Paul
>
>> -----Original Message-----
>> From: James M Snell [mailto:jasnell@gmail.com]
>> Sent: Tuesday, March 27, 2012 12:39 PM
>> To: Paul E. Jones
>> Cc: Andrew Sullivan; apps-discuss@ietf.org
>> Subject: Re: [apps-discuss] Webfinger discussion
>>
>> To be fair, there are ways of dealing with the potential for secur= ity
>> leaks of this nature with WebFinger that did not really exist with= the
>> original Finger protocol. OAuth 2, for instance. A WebFinger endpo= int
>> could choose to serve up only the most basic static information to=
>> unauthenticated requesters, but then provide a means for a request= er to
>> authenticate and request permission from the target user or provid= er to
>> acquire additional information as part of the response.
>>
>> On a side note to Paul: I did have some additional general comment= s on the
>> WebFinger spec itself, I wanted to ask where such comments would b= e best
>> directed for discussion.
>>
>> - James
>>
>> On Tue, Mar 27, 2012 at 9:15 AM, Paul E. Jones <paulej@packetizer.com> >> wrote:
>> > I agree it would be useful to add text about sharing informat= ion that
>> > might be dynamic in nature (e.g., current user location).
>> >
>> > We'll add text along those lines to the next draft. =A0An= y other
>> > security considerations we should note?
>> >
>> > Paul
>> >
>> >> -----Original Message-----
>> >> From: apps-discuss-bounces@ietf.org
>> >> [mailto:apps-discuss-bounces@ietf.org]
>> >> On Behalf Of Andrew Sullivan
>> >> Sent: Tuesday, March 27, 2012 4:47 AM
>> >> To: apps-discuss@ietf.org
>> >> Subject: Re: [apps-discuss] Webfinger discussion
>> >>
>> >> On Mon, Mar 26, 2012 at 02:31:30PM -0400, Bob Wyman wrote= :
>> >>
>> >> > un-recommended!). If people did, in fact, use WebFin= ger to record
>> >> > such stuff, the concerns you mentioned would be rele= vant. Thus, it
>> >> > might make sense for the Security Considerations sec= tion to suggest
>> >> > that one should think carefully before using WebFing= er to provide
>> >> > such dynamic
>> >> information.
>> >>
>> >> Right, that's most of what I was trying to say. =A0I = 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 repos= itory has
>> >> some potential security side effects (not just privacy on= es, but
>> >> those too, of
>> >> course) that are not clearly highlighted in the security<= br> >> considerations.
>> >> I suppose one could argue that facebook's (or pick yo= ur 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
>> >> ajs@anvilwalrusden.com
>> >> _______________________________________________
>> >> apps-discuss mailing list
>> >> apps-discuss@ietf.org
>> >> https://www.ietf.org/mailman/listinfo/apps-discuss
>> >
>> > _______________________________________________
>> > apps-discuss mailing list
>> > ap= ps-discuss@ietf.org
>> > https://www.ietf.org/mailman/listinfo/apps-discuss
>
_______________________________________________
apps-discuss mailing list
apps-discuss@iet= f.org
https://www.ietf.org/mailman/listinfo/apps-discuss<= /p>

Questo messaggio e i suoi allegati sono indirizzati = esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altr= a azione derivante dalla conoscenza di queste informazioni sono rigorosamen= te 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, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.=


_______________________________________________
apps-discuss mailing list
apps-discuss@iet= f.org
https://www.ietf.org/mailman/listinfo/apps-discuss<= /p>

=A0

Q= uesto messaggio e i suoi allegati sono indirizzati esclusivamente alle pers= one indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigoro= samente vietate. Qualora abbiate ricevuto questo documento per errore siete= cortesemente pregati di darne immediata comunicazione al mittente e di pro= vvedere alla sua distruzione, Grazie.

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

3D"rispettaRispetta l'ambiente. Non stampa= re questa mail se non =E8 necessario.


--20cf300faca1c5af2104bc517711-- --20cf300faca1c5af2304bc517712 Content-Type: image/jpeg; name="logo Ambiente_foglia2.jpg" Content-Transfer-Encoding: base64 Content-ID: <00000000000000000000000000000003@TI.Disclaimer> X-Attachment-Id: dcc9f1527df0e316_0.1 R0lGODlhGgAoANU5AEiFNnikNyRvNcvYOafCOEOEW3DO3jB2NqjGs9ny9o+zOIOrN+L1+G+ggbzo 8GCUN1SNNv///zx+NrPJOL/ROYPV44zY5YuzmrfQwCZxQlKNaMXZzOfy8NTi2TV6TuLs5vX8/ez5 +4yzmtTj2cXr8mCXdKni62ycN5/f6aDf6X2qjrPl7rLl7Zu6OJbb53nS4PH188bs8sXZzfH18pq9 p0SDWxhnNWbL3NfgOf///wAAAAAAAAAAAAAAAAAAAAAAACH5BAEAADkALAAAAAAaACgAAAb/wJxw SBQ6WMWkMmm6kZbQ5OvmjFoT1JuBYYWmsrcXqJvEgm8WctFypnI66pyjfXMhCmqGgR4r2S5dIBV0 FjI2h3BRX20VHAUCEjZ4UHNtFo42BA+HCEskbQYOIwU2CjgBNgAZM0kMbSYcIjYCBDg4LTYLf0V6 YCghNBk2DwO2OASZqkS9VBYMCB6pE8bGucidOYJUoaOptdQTFDg2ATgHGkIs2wyyAqbUtgICCwfl uh8ge1sNNhDF8LYiHYKAg4INBJUS8FsAEF6AA6lsHWjg4gYKDDZONGwIAIAtCAX2hPAgYSNHj6ds 3KiA8V3DAQGm2epoS4HKFQ0EmMRhc97Mwge2kN1IoIGgyQECD5wQUO6YygTkdtpCdSgqDl0VoDaV OmDBpm+oTCQoABQgBZfGbIrDAUBDAgcNDnDs98/WA504Buxa0RKgzVkB/h0oi+pDjgQhHtU1RgDi oY6l8gpAJyTBCBsSFtuC6XjWTBuJhIRAgFkmwAmoAkM4mCQCBmEB1sIDIKAFRGytYfDrt4CAuAkn qnrYYCXCBxGkqlYtgbtLhOcbMNSw0SBOEmg2VFj/sGHDhRLCNBC3fqFqARWhowQBADs= --20cf300faca1c5af2304bc517712--