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

[Melvin Carvalho <[e-mail]>]

On 19 June 2013 15:00, Goix Laurent Walter <
[e-mail]> wrote:

> 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...
>

I think the original webfinger was motivated by email identiiers and acct:
came in later

http://code.google.com/p/webfinger/

"WebFinger is about making email addresses more valuable, by letting people
attach public metadata to them"


>
> 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.
>
>
>
> ---------- Forwarded message ----------
> From: Goix Laurent Walter <[e-mail]>
> To: "Paul E. Jones" <[e-mail]>, 'Pete Resnick' <
> [e-mail]>, 'The IESG' <[e-mail]>
> Cc: "[e-mail]" <[e-mail]>, "
> [e-mail]" <[e-mail]>, "
> [e-mail]" <
> [e-mail]>
> Date: Thu, 11 Apr 2013 10:30:35 +0200
> Subject: [webfinger] R: Pete Resnick's Discuss on
> draft-ietf-appsawg-webfinger-12: (with DISCUSS and COMMENT)
> 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-fromrelation 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
>
>