Subject: [webfinger] Working Group Last Call for draft-ietf-appsawg-webfinger-09

From: Salvatore Loreto <[email-masked]>
Date: Mon, 28 Jan 2013 20:13:48 +0200

Dear WG partecipants,

I would like to initiate a 2 weeks WG Last Call on
draft-ietf-appsawg-webfinger-09.txt ("WebFinger")
http://tools.ietf.org/id/draft-ietf-appsawg-webfinger-09.txt

Please send your reviews, as well as expression of support regarding
document readiness for IESG (or not) either to the *webfinger* mailing 
list ([email-masked]),
or directly to the WG chairs (Murray Kucherawy and myself).

Comments like "I've read the document and it is Ok to publish" or
"I've read the document and it has the following issues"
are useful and would be gratefully accepted by chairs.

The WG LC will end on Friday, February 8th.

Thank you,
Salvatore as an APPSAWG co-chair.

---

From: James M Snell <[email-masked]>
Date: Tue, 29 Jan 2013 10:03:23 -0800

I'm really just now starting to turn my attention to the acct uri aspect of
the WebFinger discussion.. generally speaking I'm +1 on the current draft.
When going through various implementation scenarios, however, one thought
did strike me, although it may be a bit too late in the game to put this on
the table at all. I apologize for making this late suggestion...

In some scenarios, such as hosted cloud application environments, a service
provider may wish to host the information about a given user within a
different domain. For instance, suppose Company Foo.com utilizes services
from ISV Bar.com. The user accounts, however, are drawn from Foo.com, but
Bar.com is the provider that actually hosts the profiles and account
information. What I want is something that identifies the user account AND
the service provider.

Example:

  acct:[email-masked]?provider=bar.com

In a WebFinger type of scenario, resolving this would involve something
like...

  GET /.well-known/webfinger?resource=[email-masked]
  Host: bar.com

Encoding the third party provider into the URL in this way provides a
fairly flexible way of enabling the third party support without complicated
redirects from foo.com to bar.com. It also gives domains a way of enabling
bits of information to be shared from multiple sources...
acct:[email-masked]?provider=isv1.com vs.
acct:[email-masked]?provider=isv2.com

To enable this kind of thing, it would be helpful if the basic acct URI
syntax allowed for optional parameters like the mailto URI scheme does
(RFC2368). The specific parameters themselves can be figured out later...

- James

On Mon, Jan 28, 2013 at 10:16 AM, Salvatore Loreto <
[email-masked]> wrote:

>  FYI
>
> the 2 weeks WGLC on draft-ietf-appsawg-webfinger is started.
> Please see the mail below and note that the right venue for discussion is
> the *webfinger* mailing list
>
> best regards
> Salvatore
>
> -------- Original Message --------  Subject: [webfinger] Working Group
> Last Call for draft-ietf-appsawg-webfinger-09  Date: Mon, 28 Jan 2013
> 20:13:48 +0200  From: Salvatore Loreto <[email-masked]><[email-masked]>  To:
> <[email-masked]> <[email-masked]>  CC: Murray S. Kucherawy
> <[email-masked]> <[email-masked]>
>
>
> Dear WG partecipants,
>
>
> http://tools.ietf.org/id/draft-ietf-appsawg-webfinger-09.txt<http://tools.ietf.org/id/draft-ietf-appsawg-acct-uri-02.txt>
>
>
> document readiness for IESG (or not) either to the **webfinger** mailing
> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss
>
>

---

From: Kingsley Idehen <[email-masked]>
Date: Tue, 29 Jan 2013 13:11:57 -0500

On 1/29/13 1:03 PM, James M Snell wrote:
> I'm really just now starting to turn my attention to the acct uri 
> aspect of the WebFinger discussion.. generally speaking I'm +1 on the 
> current draft. When going through various implementation scenarios, 
> however, one thought did strike me, although it may be a bit too late 
> in the game to put this on the table at all. I apologize for making 
> this late suggestion...
>
> In some scenarios, such as hosted cloud application environments, a 
> service provider may wish to host the information about a given user 
> within a different domain. For instance, suppose Company Foo.com 
> utilizes services from ISV Bar.com. The user accounts, however, are 
> drawn from Foo.com, but Bar.com is the provider that actually hosts 
> the profiles and account information. What I want is something that 
> identifies the user account AND the service provider.
>
> Example:
>
> <http://acct:[email-masked]?provider=bar.com>
>
> In a WebFinger type of scenario, resolving this would involve 
> something like...
>
> <mailto:[email-masked]>
>   Host: bar.com <http://bar.com>
>
> fairly flexible way of enabling the third party support without 
> complicated redirects from foo.com <http://foo.com> to bar.com 
> <http://bar.com>. It also gives domains a way of enabling bits of 
> information to be shared from multiple sources... 
> acct:[email-masked]?provider=isv1.com 
> <http://acct:[email-masked]?provider=isv1.com> vs. 
> <http://acct:[email-masked]?provider=isv2.com>
>
> To enable this kind of thing, it would be helpful if the basic acct 
> URI syntax allowed for optional parameters like the mailto URI scheme 
> does (RFC2368). The specific parameters themselves can be figured out 
> later...

+1

Kingsley
>
> - James
>
>
>
>
>
>
> On Mon, Jan 28, 2013 at 10:16 AM, Salvatore Loreto 
> <[email-masked] <mailto:[email-masked]>> 
> wrote:
>
>     FYI
>
>     -------- Original Message --------
>     Subject: 	[webfinger] Working Group Last Call for
>     draft-ietf-appsawg-webfinger-09
>     Date: 	Mon, 28 Jan 2013 20:13:48 +0200
>     From: 	Salvatore Loreto <[email-masked]>
>     <mailto:[email-masked]>
>     To: 	<[email-masked]> <mailto:[email-masked]>
>     CC: 	Murray S. Kucherawy <[email-masked]>
>     <mailto:[email-masked]>
>
>
>
>     Dear WG partecipants,
>
>
>     <http://tools.ietf.org/id/draft-ietf-appsawg-acct-uri-02.txt>
>
>
>     document readiness for IESG (or not) either to the **webfinger**
>     mailing list ([email-masked] <mailto:[email-masked]>),
>     [email-masked] <mailto:[email-masked]>
> webfinger mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/webfinger

-- 

Regards,

Kingsley Idehen	
Founder & CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/112399767740508618350/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen

---

From: Gonzalo Salgueiro <[email-masked]>
Date: Tue, 29 Jan 2013 13:12:22 -0500

Thanks James. I'm just trying to sort through this a bit. Is this a WF LC comment or more of an acct URI LC comment?

Cheers,

Gonzalo

On Jan 29, 2013, at 1:03 PM, James M Snell <[email-masked]> wrote:

> I'm really just now starting to turn my attention to the acct uri aspect of the WebFinger discussion.. generally speaking I'm +1 on the current draft. When going through various implementation scenarios, however, one thought did strike me, although it may be a bit too late in the game to put this on the table at all. I apologize for making this late suggestion...
> 
> In some scenarios, such as hosted cloud application environments, a service provider may wish to host the information about a given user within a different domain. For instance, suppose Company Foo.com utilizes services from ISV Bar.com. The user accounts, however, are drawn from Foo.com, but Bar.com is the provider that actually hosts the profiles and account information. What I want is something that identifies the user account AND the service provider. 
> 
> Example: 
> 
> In a WebFinger type of scenario, resolving this would involve something like...
> 
> Encoding the third party provider into the URL in this way provides a fairly flexible way of enabling the third party support without complicated redirects from foo.com to bar.com. It also gives domains a way of enabling bits of information to be shared from multiple sources... acct:[email-masked]?provider=isv1.com vs. acct:[email-masked]?provider=isv2.com
> 
> To enable this kind of thing, it would be helpful if the basic acct URI syntax allowed for optional parameters like the mailto URI scheme does (RFC2368). The specific parameters themselves can be figured out later...
> 
> - James
> 
> 
> 
> 
> 
> 
> On Mon, Jan 28, 2013 at 10:16 AM, Salvatore Loreto <[email-masked]> wrote:
> FYI
> 
> Subject:	[webfinger] Working Group Last Call for draft-ietf-appsawg-webfinger-09
> To:	<[email-masked]>
> document readiness for IESG (or not) either to the *webfinger* mailing list ([email-masked]),

---

From: James M Snell <[email-masked]>
Date: Tue, 29 Jan 2013 10:25:44 -0800

Umm... more of an acct URI LC comment really, although it could potentially
impact WF impls down the road.

On Tue, Jan 29, 2013 at 10:12 AM, Gonzalo Salgueiro <[email-masked]>wrote:

> Thanks James. I'm just trying to sort through this a bit. Is this a WF LC
> comment or more of an acct URI LC comment?
>
> Cheers,
>
> Gonzalo
>
> > I'm really just now starting to turn my attention to the acct uri aspect
> of the WebFinger discussion.. generally speaking I'm +1 on the current
> draft. When going through various implementation scenarios, however, one
> thought did strike me, although it may be a bit too late in the game to put
> this on the table at all. I apologize for making this late suggestion...
> >
> service provider may wish to host the information about a given user within
> a different domain. For instance, suppose Company Foo.com utilizes services
> redirects from foo.com to bar.com. It also gives domains a way of
> enabling bits of information to be shared from multiple sources...

---

From: Gonzalo Salgueiro <[email-masked]>
Date: Tue, 29 Jan 2013 13:33:57 -0500

That was more or less my assessment as well. There is a separate thread going on in apps-discuss for acct URI LC comments.   I think this needs  to be featured there and based on its resolution we will figure out if requires new/different text on the WF draft.

Cheers,

Gonzalo

On Jan 29, 2013, at 1:25 PM, James M Snell <[email-masked]> wrote:

> Umm... more of an acct URI LC comment really, although it could potentially impact WF impls down the road.
> 
> 
> On Tue, Jan 29, 2013 at 10:12 AM, Gonzalo Salgueiro <[email-masked]> wrote:

---

From: Melvin Carvalho <[email-masked]>
Date: Tue, 29 Jan 2013 19:40:38 +0100

> are useful and would be gratefully accepted by chairs.

I have read the document and I think the JRD should have it's own MIME
type, which the client SHOULD send with the HTTP(S) GET.