[webfinger] R: [appsawg] #12: Semantic gap for the client side

[Goix Laurent Walter <[e-mail]>]

Hi all,

I am catching up as well a bit late and would like to move things forward for those realistic use cases. Some comments inline...

[snip]
> >
> > 1.  Explicitly state that WebFinger is a framework and that the information
> to be returned for specific "rel" link relation types for specific kinds of
> URIs is outside the scope of the specification, but is intended to be defined
> by other specifications.
>
> I'm okay with this, so long as we keep clear that in addition to a framework
> there is a real protocol definition here that clearly prescribes on-the-wire
> behavior.

[walter] +1. Actually OMA SNEW is another spec (besides OpenID Connect) that leverages webfinger for (mobile) federated social networks. I re-attach a mail I sent a couple of months ago with a related example after some discussion already on the examples section. (feedback/revision is welcome)

> >
> > 2.  We could establish a registry indexed by "rel" link relation values
> pointing to documents that define this information.  For instance, we could
> then register the "rel" value "http://openid.net/specs/connect/1.0/issuer" and
> point it to http://openid.net/specs/openid-connect-discovery-1_0.html, which
> defines the meaning of that link relation.  Other link relation definitions
> could then also use that registry.
>
> Sure. This is a simple step to take to provide clarity on existing uses of WF.

[walter] link rel registry already exist at IANA and we should probably leverage on that, which is also useful for other contexts such as embedding such link rels in atom feeds or html pages for example. But surely 1) we can define new official link rel tokens that fit concrete use cases, 2) we may have an informal registry for the link rel URIs (and could use the one from Paul on packetizer as basis)

[snip]

> >
> > 4.  Since people are finding the examples problematic, we could remove them,
> or possibly only keep the OpenID Connect one, which is concrete and being used
> in practice.  Or in fact, we could add a second OpenID Connect example - so
> that there's one with the resource being a URL and another with the resource
> using e-mail address syntax.  We could also bring over the apparently-
> innocuous "copyright" and "author" examples from RFC 6415, if those would
> cause people less consternation.  But the device and e-mail examples seem to
> be generating more heat than light.
>
> I've very reluctantly suggested this to Paul as well.  Not because I don't
> like the examples.  In fact, I consider them some of the most useful text for
> implementers and for their value in quickly relaying the power of current
> usage and future potential of the protocol.  In the interest of an expeditious
> resolution to this stalemate I'd be willing to remove the two examples giving
> problems, though I'd warn that we do have tangible useful information loss
> (e.g., no demonstrated use of properties, etc.).  My position on this is only
> because I expect to write future documents that will allow us to resurrect
> these deleted examples.
>
> BTW - The addition of a supplementary OpenID Connect example seems reasonable
> and helpful.

[walter] i would really avoid removing the whole example section. This is very much helpful for developers to understand the protocol, and the document format (we re-defined JRD in this doc so it makes a lot of sense to show examples of this *new* data model). Besides openid connect I am proposing the oma snew case, but one or more fictitious examples that possibly don't harm any community (no email config, no aggrsrv, etc) and that moreover could better showcase the expressiveness of JRD would be useful IMHO.

> >
> > 5.  We could remove all references to and discussion of the acct: URI, since
> WebFinger actually has no dependency upon it.  Other specifications can still
> specify that it be used in particular contexts with WebFinger, as OpenID
> Connect does.
>
> This is tragic considering they were so closely intertwined that they were one
> and the same document at one point. That said, if it helps get us to
> publication quickly...
> >
> > I realize that the examples provide more context for developers but if
> they're standing between us and finishing the spec it would be better for them
> to go.  Likewise, if acct: is standing between us and finishing, it should go
> too.

[walter] webfinger was originally very much motivated by "account identifiers" (then became acct: URI) and as such would deserve a mention as it currently states. I don't believe that its mention limits the proposal (it clearly states that any other URI scheme is valid) but clarifies the original intent. I do not see why it would help removing it, but if it makes it ship faster...

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.

--- Begin Message ---

Dear all,

After reading this thread and the various ballots, I'd like to help the DISCUSSion and hopefully clarify (part of) the doubts by proposing an example of usage of webfinger within federated social networks. This example is derived from the OMA Social Network Web specification, which references Webfinger for this specific purpose.
I'd also like to recall (as Paul anticipated talking about rfc6415) that social network federation was actually the first use case of the original webfinger community spec, and as such imo well deserves an example using this new spec as it may become extremely relevant in the next years.

Of course improvements are welcome if the generic idea is sound.

Walter

---
3.x Federated Social Networks
In the context of interoperable, federated, social networks, the Webfinger discovery process is used by a SN Server when receiving a request from an SN Client on behalf of a user asking to interact with a user identified by his SN account eg acct:[e-mail]. In particular the SN Server identifies whether it is authoritative for the recipient (i.e. the domain of his/her account is "locally" managed by this SN Server) or whether it pertains to another remote SN domain/provider. If the recipient's address corresponds to a "acct:" address, which domain-part corresponds to a remote domain, the SN Server can locate the recipient's SN Server based on this domain-part and trigger the Webfinger discovery process for that recipient (the "resource").
This process can hence be triggered when receiving requests to follow remote users or when receiving reactions (e.g. comments, replies, mentions) that relate to social activities of remote users, etc. Depending on the incoming request from the client, the SN Server may be interested in some specific link rels that will be used to contact the remote SN Server on the related endpoint(s). SN Servers can cache the information provided in the retrieved descriptor and/or issue conditional requests at a later stage to check for updates of this information, subject to the mechanisms defined in [RFC 2616] section 13.

The following JRD is an example of a user descriptor returned by an SN Server for a Webfinger query to user account acct:[e-mail]. In this request no specific rel is mentioned as it may be useful for the requesting SN Server to cache to entire descriptor for future needs.

{
       "subject" : "acct:[e-mail]",
       "properties" :
       {
           "http://salmon-protocol.org/ns/magic-key" : "RSA.mVgY8RN6URBTstndvmUUPb4UZTdwvwmddSKE5z_jvKUEK6yk1u3rrC9yN8k6FilGj9K0eeUPe2hf4Pj-5CmHww.AQAB"
       },
       "links" :
       [
         {
           "rel" : "http://portablecontacts.net/spec/1.0",
           "href" : "http://example.com/api/people"
         },
         {
           "rel" : "http://portablecontacts.net/spec/1.0#me",
           "href" : "http://example.com/api/people/joe"
         },
         {
           "rel" : "http://ns.opensocial.org/2008/opensocial/people",
           "href" : "http://example.com/api/people"
         },
         {
           "rel" : "http://webfinger.net/rel/profile-page",
           "type" : "text/html",
           "href" : "http://example.com/profiles/joe"
         },
         {
           "rel" : "describedby",
           "type" : "text/html",
           "href" : "http://example.com/profiles/joe"
         },
         {
           "rel" : "http://webfinger.net/rel/avatar",
           "href" : "http://example.com/profiles/joe/photo"
         },
         {
           "rel" : "http://schemas.google.com/g/2010#updates-from",
           "type" : "application/atom+xml",
           "href" : "http://example.com/activities/joe"
         },
         {
           "rel" : "salmon",
           "href" : "http://example.com/salmon/joe"
         }
       ]
}

Depending on the original request from the client the SN Server will typically read a specific link rel and invoke the related endpoint. For example it can read the http://schemas.google.com/g/2010#updates-from relation link of type "application/atom+xml" to access the user's activity stream feed or the http://portablecontacts.net/spec/1.0 relation link to access personal user information such as his profile or relationships. The actual access to such endpoints and the retrieved data ,if any, will be subject to the remote SN policies and user settings.

> -----Messaggio originale-----
> Da: [e-mail] [mailto:[e-mail]] Per conto
> di Paul E. Jones
> Inviato: giovedì 11 aprile 2013 5.40
> A: 'Pete Resnick'; 'The IESG'
> Cc: [e-mail]; [e-mail]; draft-ietf-appsawg-
> [e-mail]
> Oggetto: Re: [webfinger] Pete Resnick's Discuss on draft-ietf-appsawg-
> webfinger-12: (with DISCUSS and COMMENT)
>
> Pete,
>
> > [All: As I noted earlier to the Webfinger mailing list, I have Cc'ed
> > this
> > to the Webfinger list along with the document authors, the document
> > shepherd, and the rest of the IESG.
> >
> > Also note that I intend to DISCUSS this until Thursday. If I get no
> > further support from the IESG and/or the WG that this is a serious and
> > showstopper problem, I will simply ABSTAIN on both this and on the
> > -acct-uri document (on which I also currently have an open DISCUSS
> > position). But it looks like Richard and I are in some agreement on
> > this.]
> >
> > There appears to be a big giant semantic gap for the client side of this
> > protocol. I can find nothing in the document that indicates to the
> > client
> > how it shall determine what sort of URI to use is the resource part of
> > the query or what the semantics of any given URI are supposed to be. I
> > suspect that the semantics are so underspecified that there could not
> > possibly be interoperable implementations without lots of out-of-band
> > information.
>
> If you are seeking information related to a user account, then the
> specification recommends the use of the "acct" URI.  Use of other URI types is
> not fully specified and no recommendations are given.  Syntactically, the
> server behavior will be the same for any type of URI.  The only gap is knowing
> what set of link relations type to expect for a given URI scheme.  Do you use
> "mailto" or "acct"?  We had a lot of debate over that for years and settled on
> "acct".
>
> So what should one expect if one issued a query like this?
>
> $ curl https://packetizer.com/.well-
> known/webfinger?resource=http://www.packetizer.com
>
> I would expect it to return information about that URL.  The link relation
> types returned might be "copyright" or "author" or other.  It would be types
> that are valid for a web page.
>
> > The first example provides a mapping from an email address (or perhaps a
> > mailto URI; that's not clear) to an acct URI, but neither the example
> > nor
> > anything in the rest of the document gives any clue why you would choose
> > to query an "acct" URI based on the contents of an email message. I
> > think
> > the assumption is that if there is an email address, there must be some
> > sort of "account" associated with it, and therefore querying the host on
> > the RHS of the "@" for that account will get some interesting
> > information. But I don't see any reason to choose an "acct" scheme over
> > "mailto" or "smtp" or "email" or "foobar"; as far as I can tell, the
> > choice is semantics-free.
>
> Again, this was a 3 year long discussion.  You're right that it could be
> anything.  We even argued to use no URI at all and just use "user@domain".
> However, it finally decided to use "acct".  It identifies an account at a
> domain.  It does not identify an email address.  Using mailto URI didn't fit
> Twitter, for example, as there is no email.  The same can be said for other
> services, including photo sharing services, blogs, and so forth.  If you want
> to query information about my account on a social networking site, it would
> not be an email address that would be used.
>
> > Reading the above alongside 3.3 makes me all the more suspicious: In 3.3
> > (also mentioned in 4.5), a "mailto" URI gets you configuration
> > information for all email configuration parameters. Does an "acct" URI
> > get you configuration information for email *and* xmpp *and* sip *and*
> > calendaring *and* all other configuration information (since you are no
> > longer asking for a particular protocol, but rather the general account
> > information), or do you only get "information" about the person and not
> > their account? (I might also insert privacy and security worries here,
> > but see Stephen's DISCUSS regarding that.) How can the client know what
> > sort of information it can ask for and how to get it? And for that
> > matter, how does the server tell what information to pass back? You'd
> > think there would be a hint about this in 4.3, but "rel" only seems to
> > provide for the client to request those things that the client already
> > knows about it. In particular, there appears to be no way to say, "Give
> > me user provided information, but not config information" or "Give me
> > config information, but not blog entries".
>
> The "rel" parameter is just a filter to reduce the size of the JRD down to
> only the particular link relation types of interest (e.g., "vcard", "jcard",
> "blog", "profile").
>
> If you wish to query for information about a person, you query the person's
> acct URI.  The other examples, such as use of "mailto" or "device" are just
> examples of what is possible.   As an example of how I would expect to use
> "mailto", you can see this presentation:
> http://www.ietf.org/proceedings/86/slides/slides-86-aggsrv-3.pdf
>
> However, the aggsrv group could say (if they even elected to use WF) that the
> "mailto" URI shall be used to query for configuration information related to
> email.  I don't know what they will recommend.  The WF draft shows an example
> of how one could use an email URI, but it is a non-working example since none
> of the link relation types are defined.
>
> The WF spec does not go into detail on what a client should expect to receive
> for any URI scheme, but only recommends use of "acct" to get user account
> information.  The link relations returned from such a query are in use today
> and some will be standardized (as that's next on the "to-do" list).
>
> > I find the semantics for "device" in 3.4 all-the-more mysterious. As far
> > as I can tell, this URI scheme simply means, "Give me all of the
> > information for the entire host."
>
> Well, "device" does not exist and that will likely never exist.  The only
> point with that was to demonstrate how any URI scheme could be used, including
> one intended for device identification.  And if we had one for device
> identification, it might return that kind of information.  Again, this is just
> a non-normative example showing broadly what we can do with WF.
>
> > Again, the semantics of all of these interactions seem so underspecified
> > that I don't understand how interoperation is supposed to happen.
>
> Yeah, this definitely was not intended to be defined.  When or if we decided
> to use WF for this purpose, it would be defined in another spec.  However, I
> would expect the syntax and procedures for making the request to the server to
> be the same as querying for an account URI.
>
> > This also leaves me with the question about why the resource query part
> > is a URI at all. It seems to me that the resource you are asking about
> > is
> > not a URI (or URN) at all; it's simply an identifier for an entity that
> > the particular host knows about. Given that, why not pass a simple
> > identifier? (See http://datatracker.ietf.org/doc/draft-ietf-radext-nai/
> > for example.) If the scheme is not providing any particular semantics
> > about the response, I see no reason to provide the scheme. If more
> > semantics (beyond rel) are needed, another parameter indicating the type
> > of identifier being used seems much more appropriate than using a URI
> > scheme.
>
> URI schemes allow for a natural separation.  And, a WF server for a domain
> could know all kinds of information about itself.  It would know who authored
> web pages on the domain.  It would know information about account holders on
> the domain.  There was back and forth, as I noted above, as to whether we
> needed "acct" or not.  In the end, it was agreed to identify information about
> users -- stuff users share or that are shared within a company (e.g., employee
> pictures or contact info).
>
> Years of work on this topic resulted in RFC 6415.  RFC 6415, in fact, is what
> people had envisaged for "webfinger".  It defined a well-known location called
> "host-meta" and a different link relation called "LRDD" for querying
> information about a particular URI.
>
> The challenge with RFC 6415 is that it too so long to move forward that by the
> time it was done, JSON had become the favored syntax language, people wanted
> to mandate use of TLS for a variety of security reasons, people did not want
> two round trips to the server to return the JRD.  So, we set about fixing all
> of the gripes people had with RFC 6415.  We removed XML entirely, we fully
> documented JRD, the server does the merging of host-meta and LRDD documents
> (though not described that way for simplicity's sake), TLS was mandated, and
> we introduced the "rel" parameter to allow for selecting one or a few types of
> links to reduce the size of the document.
>
> RFC 6415 uses any type of URI.  This is useful, since the URI scheme does
> provide separation in namespace and since we do want to allow retrieval of a
> set of link relations for those URIs -- web pages (http), user accounts
> (acct), tel URIs (tel), etc.  The only point of confusion, I think, is "what
> do we do with mailto, sip, h323, telnet, etc.?"  Well, we're not prescribing
> that.  That would be documented in a document that wants to use those other
> URIs.  They might be used to configure a device or help route a call or
> whatever.  We only have examples of possible use, but we do not specify their
> use.
>
> Paul
>
>
> _______________________________________________
> webfinger mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/webfinger

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.

_______________________________________________
webfinger mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/webfinger

--- End Message ---