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

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

> > 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.
> >
>
> This sounds reasonable, though I would add a third column (well,
> actually I would make it the first column of 3) called "Service". In
> this case, the service would be "Open ID Connect Issuer". As time goes
> on, I'd expect there to be things like "Mail Client Configuration",
> "User Account Info", and other such entries.
>
> > 3.  Explicitly state that the link relation types that will be returned from
> server when no "rel" parameter is used is entirely dependent upon the services
> supported by that host, and that, in the general case, clients must be
> prepared for the response to be the empty set for any particular resource.
> >
>
> I've always found this a weird case and never understood why you'd want
> to allow queries without "rel" parameters; I don't understand why a
> client would ever want to do that. But if you're going to do that, this
> explanation seems useful. As I've said a few times now, what this
> document is missing is some hint of how the client is going to figure
> out what it needs to do.

[walter] is there then interest for creating a new concept of "rel sets" (similarly to what you called "Service") that could have a unique name/URI (in case of simple token a registry may be useful) and would be documented in an external spec as a specific list of rels? This may help in querying on wf with a single param (avoiding to list explicitly all rels) and at the same time facilitate interop so that the client could explicitly state what it is looking for.
"openidconnect" could be one of them (no matter how many rels it covers, which would be listed in the openidconnect spec), , the "oauth" related rels could be another, and others may be created eg for federated social web (thinking of salmon, pubsub, etc) link rels...

Would this make the spec too complex if we define such additional (optional) parameter and manage the naming conventions just like for rels ?

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.