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

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

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]>
To: 	<[email-masked]>
CC: 	Murray S. Kucherawy <[email-masked]>

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: "Paul E. Jones" <[email-masked]>
Date: Tue, 29 Jan 2013 22:31:51 -0500

James,

Since this is really an acct URI question, I think it should be redirected back to the apps-discuss list.

One challenge I see with this kind of syntax is that the account information for a user is not necessarily always hosted at any certain provider.  Perhaps when acct: is used with WebFinger, the domain foo.com redirects the request to a different domain.  Perhaps for some other protocol that might utilize acct:, the means through which the information is returned is entirely different.  And what if the “hosting provider” changes next week?  I would not want a URI like acct:[email-masked] to become invalid simply because I decide to host my account information at a different provider next week.

Paul

From: [email-masked] [mailto:[email-masked]] On Behalf Of James M Snell
Sent: Tuesday, January 29, 2013 1:03 PM
To: Salvatore Loreto
Cc: [email-masked]
Subject: Re: [webfinger] [apps-discuss] Working Group Last Call for draft-ietf-appsawg-webfinger-09

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

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  <mailto:[email-masked]> <[email-masked]>

To: 

 <mailto:[email-masked]> <[email-masked]>

CC: 

Murray S. Kucherawy  <mailto:[email-masked]> <[email-masked]>

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 <http://tools.ietf.org/id/draft-ietf-appsawg-acct-uri-02.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). 

Thank you, 

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

---

From: Salvatore Loreto <[email-masked]>
Date: Wed, 30 Jan 2013 10:41:11 +0200

in principle I am not against to allow the basic 'acct' URI syntax for 
optional parameter.

However I am not convinced of the need to specify one for the actual 
cloud provider
for several reasons:
- the actual cloud provider can change over the time
- one user can decide to host different services to different cloud 
providers
- if a user has to provide the 'acct' URI with the 'provide' parameter
I don't understand the advantage to disclosure 
acct:[email-masked]?provider=isv1.com 
<http://acct:[email-masked]?provider=isv1.com>
vs disclosing directly acct:[email-masked] 
<http://acct:[email-masked]?provider=isv1.com>

/Salvatore

On 1/30/13 5:31 AM, Paul E. Jones wrote:
>
> James,
>
> Since this is really an acct URI question, I think it should be 
> redirected back to the apps-discuss list.
>
> One challenge I see with this kind of syntax is that the account 
> information for a user is not necessarily always hosted at any certain 
> provider.  Perhaps when acct: is used with WebFinger, the domain 
> foo.com redirects the request to a different domain.  Perhaps for some 
> other protocol that might utilize acct:, the means through which the 
> information is returned is entirely different.  And what if the 
> “hosting provider” changes next week?  I would not want a URI like 
> acct:[email-masked] to become invalid simply because I decide 
> to host my account information at a different provider next week.
>
> Paul
>
> *From:[email-masked] [mailto:[email-masked]] 
> *On Behalf Of *James M Snell
> *Sent:* Tuesday, January 29, 2013 1:03 PM
> *To:* Salvatore Loreto
> *Cc:* [email-masked]
> *Subject:* Re: [webfinger] [apps-discuss] Working Group Last Call for 
> 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>
>
> <mailto:[email-masked]>
>
>   Host: bar.com <http://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 <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. 
> acct:[email-masked]?provider=isv2.com 
> <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...
>
> - James
>
> On Mon, Jan 28, 2013 at 10:16 AM, Salvatore Loreto 
> <[email-masked] <mailto:[email-masked]>> 
> wrote:
>
> FYI
>
> *Subject: *
> *Date: *
> *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]>

---

From: Mike Jones <[email-masked]>
Date: Wed, 30 Jan 2013 17:16:40 +0000

If we were to support this, a more consistent syntax would be to always have the provider be the part to the right of the last ‘@’ and have everything else be the account identifier at the provider.  Then, for instance, acct:[email-masked]@facebook.com would be a legal identifier for my Facebook account and acct:[email-masked] would be a legal identifier for my Twitter account.  In both cases, the provider is the part after the last ‘@’.

I’m not certain this is needed, but would prefer the ‘@’ syntax to the ‘?’ syntax, if we do want to support account identifiers of the form user@domain with a provider being specified that’s different than the domain.  Whereas introducing the full ‘?’ syntax seems like overkill, and I would be against that.

                                                            -- Mike

From: [email-masked] [mailto:[email-masked]] On Behalf Of Salvatore Loreto
Sent: Wednesday, January 30, 2013 12:41 AM
To: 'James M Snell'
Cc: [email-masked]
Subject: Re: [apps-discuss] [webfinger] Working Group Last Call for draft-ietf-appsawg-webfinger-09

in principle I am not against to allow the basic 'acct' URI syntax for optional parameter.

However I am not convinced of the need to specify one for the actual cloud provider
for several reasons:
- the actual cloud provider can change over the time
- one user can decide to host different services to different cloud providers
- if a user has to provide the 'acct' URI with the 'provide' parameter
I don't understand the advantage to disclosure acct:[email-masked]?provider=isv1.com<http://acct:[email-masked]?provider=isv1.com>
vs disclosing directly  acct:[email-masked]<http://acct:[email-masked]?provider=isv1.com>

/Salvatore

One challenge I see with this kind of syntax is that the account information for a user is not necessarily always hosted at any certain provider.  Perhaps when acct: is used with WebFinger, the domain foo.com redirects the request to a different domain.  Perhaps for some other protocol that might utilize acct:, the means through which the information is returned is entirely different.  And what if the “hosting provider” changes next week?  I would not want a URI like acct:[email-masked]<mailto:acct:[email-masked]> to become invalid simply because I decide to host my account information at a different provider next week.

Paul

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of James M Snell
Sent: Tuesday, January 29, 2013 1:03 PM
To: Salvatore Loreto
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [webfinger] [apps-discuss] Working Group Last Call for draft-ietf-appsawg-webfinger-09

Example:

  acct:[email-masked]?provider=bar.com<http://acct:[email-masked]?provider=bar.com>

  GET /.well-known/webfinger?resource=[email-masked]<mailto:[email-masked]>
  Host: bar.com<http://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<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. acct:[email-masked]?provider=isv2.com<http://acct:[email-masked]?provider=isv2.com>

- James

On Mon, Jan 28, 2013 at 10:16 AM, Salvatore Loreto <[email-masked]<mailto:[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:

Date:

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,

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<http://tools.ietf.org/id/draft-ietf-appsawg-acct-uri-02.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]<mailto:[email-masked]>),
or directly to the WG chairs (Murray Kucherawy and myself).

Thank you,

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

---

From: James M Snell <[email-masked]>
Date: Wed, 30 Jan 2013 09:33:41 -0800

First off, The ? syntax is already well established practice for many URI
structures, particularly http and mailto, it makes a lot of sense to reuse
that, particularly since many existing URI parsers will give you support
for for free.

Second, the most I am suggesting for acct uri is the allowance of optional
query parameters. I am not suggesting, right now, that we ought to change
the semantics of WebFinger's resolution... but I do want to leave the door
open for alternative resolution mechanisms later. I used the ?provider=
bar.com as an example of the basic motivation for the parameters, but there
very well could be other interesting parameters that are worth considering.

Hypothetically, for instance, in the future we could have something like:

  <a href="acct:[email-masked]?rel=weblog" rel="weblog">Find my blog!</a>

Allowing for optional query parameters gives us more flexibility long term
without introducing significant new complexity now.

Additional responses to Salvatore's comments inline below...

On Wed, Jan 30, 2013 at 9:16 AM, Mike Jones <[email-masked]>wrote:

>  If we were to support this, a more consistent syntax would be to always
> have the provider be the part to the right of the last ‘@’ and have
> everything else be the account identifier at the provider.  Then, for
> instance, acct:[email-masked]@facebook.com would be a legal identifier
> for my Facebook account and acct:[email-masked] would be a legal
> identifier for my Twitter account.  In both cases, the provider is the part
> after the last ‘@’.****
>
> ** **
>
> I’m not certain this is needed, but would prefer the ‘@’ syntax to the ‘?’
> syntax, if we do want to support account identifiers of the form user@domainwith a provider being specified that’s different than the domain.  Whereas
> introducing the full ‘?’ syntax seems like overkill, and I would be against
> that.****
>
> ** **
>
>                                                             -- Mike****
>
> ** **
>
> *From:* [email-masked] [mailto:
> [email-masked]] *On Behalf Of *Salvatore Loreto
> *Sent:* Wednesday, January 30, 2013 12:41 AM
> *To:* 'James M Snell'
> *Cc:* [email-masked]
> *Subject:* Re: [apps-discuss] [webfinger] Working Group Last Call for
> draft-ietf-appsawg-webfinger-09****
>
> ** **
>
>

Yes, the provider can change but the base account id would not...

>  - one user can decide to host different services to different cloud

And a single account ID could be used a multiple cloud providers... for
instance, I use my gmail address as my login ID at quite a few locations.

> vs disclosing directly  acct:[email-masked]<http://acct:[email-masked]?provider=isv1.com>

Suppose I am an ISV hosting services for two separate companies, both of
which have a user named "joe"

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

Looking at this, there are two ways of resolving each..

1. To find out information about [email-masked]..
   a. I can send a WF request to foo.com, which redirects to isv.com, or
   b. I can send a WF request to isv.com with resource=[email-masked]
2. To find out information about [email-masked]..
   a. I can send a WF request to bar.com, which redirects to isv.com, or
   b. I can send a WF request to isv.com with resource=[email-masked]

Again, however, this is just an example. The most I am suggesting right now
is that we allow for optional query string parameters, I am not suggesting
that we define specific parameters at this time.

- James

>
>
> /Salvatore
>
>
> On 1/30/13 5:31 AM, Paul E. Jones wrote:****
>
> James,****
>
>  ****
>
> Since this is really an acct URI question, I think it should be redirected
> back to the apps-discuss list.****
>
>  ****
>
> provider.  Perhaps when acct: is used with WebFinger, the domain foo.comredirects the request to a different domain.  Perhaps for some other
> protocol that might utilize acct:, the means through which the information
> is returned is entirely different.  And what if the “hosting provider”
> changes next week?  I would not want a URI like acct:[email-masked] become invalid simply because I decide to host my account information at
> a different provider next week.****
>
>   ****
>
> Paul****
>
>  ****
>
> *From:* [email-masked] [mailto:[email-masked]<[email-masked]>]
> draft-ietf-appsawg-webfinger-09****
>
>  ****
>
> 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
> 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****
>
>  ****
>
> 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****
>
> -------- 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,
>
>
> document readiness for IESG (or not) either to the **webfinger** mailing
> ****
>  ****
> https://www.ietf.org/mailman/listinfo/apps-discuss****
>
>  ****
>
> ** **
>