Re: [apps-discuss] WF flow with rel parameter

[Eran Hammer <[e-mail]>]

There are two separate issues here:

1. Adding support for RFC 6570 - this adds complexity (but might have happened if 6570 was finished earlier).
2. Define additional parameters (right now, only 'uri' is defined as a template input).

EH

> -----Original Message-----
> From: [e-mail] [mailto:apps-discuss-
> [e-mail]] On Behalf Of John Bradley
> Sent: Wednesday, April 25, 2012 7:49 AM
> To: Paul E.Jones
> Cc: [e-mail]
> Subject: Re: [apps-discuss] WF flow with rel parameter
> 
> Taking a closer look at http://tools.ietf.org/html/rfc6570
> 
> The lrdd template can be something like:
> https://example.com/lrdd/?format=json{&uri,rel}
> or
> https://example.com/lrdd/?format=json&resource={uri}{&rel}
> 
> So it probably comes down to me asking for WF to conform to rfc6570 for
> LRDD template construction or at least adding the {?} and {&} templates from
> rfc6570.
> 
> That way people who want to host JRD's as a service on another host don't
> lose the ability to filter.
> 
> John B.
> 
> On 2012-04-25, at 2:25 AM, Paul E. Jones wrote:
> 
> > John,
> >
> > The "rel" parameter is something we still need to discuss, so not is as good
> a time as any.
> >
> > What "rel" does is act as a filter.  For the most part, the only purpose it
> serves is to help reduce the number of link relations that might be sent from
> the server.  So, if a user had 1,000 different link relations, this might reduce
> the returned message to containing only 1.  However, if a user has more than
> one link relation of the same type, all of them would match and be returned.
> >
> > When you say the host cannot support re-write rules, I assume you mean it
> does not support the URI parameters on host-meta?  In that case, yes, the
> parameters are ignored and you get just the host-meta document.
> >
> > The only URI template defined in RFC 6415 is "{uri}" (see 3.1.1.1).  There are
> no other URI template values defined.  (Note: this whole section exists only
> because RFC  6570 did not yet exist, I think.
> >
> > In any case, we could define a new URI template, but then we would be
> putting an optimization in place for LRDD.  If host-meta is not going to
> support the "rel" URI parameter, why would LRDD?  It would also mean that
> the LRDD logic would have to be ready to receive a URI parameter that is not
> replaced, since some clients would only change {uri} and leave {rel} there.
> That would introduce more conditional logic in the server.  This would also
> present issues with static sites.  (Of course, one might be able to use Apache
> re-writing rules to get around that problem, but it certainly would not work
> for "real" static sites.)
> >
> > Personally,  I'd prefer to not add the "rel" parameter to LRDD, since I think
> optimization using "rel" would always be done on host-meta.  That said, I
> question the value of "rel" entirely.  Do you think it's useful to have this filter
> at all?  Is there really a risk that a site might return 1,000 link relations that the
> client would have to step over?
> >
> > Paul
> >
> > From: John Bradley [mailto:[e-mail]]
> > Sent: Tuesday, April 24, 2012 10:17 PM
> > To: Paul E. Jones
> > Cc: [e-mail]
> > Subject: WF flow with rel parameter
> >
> > Paul,
> >
> > Sorry I hit send on the previous message with a typo.
> >
> > I am looking at how the flows in WF might work for openID.
> >
> > Let's set aside the XML issue for the moment and focus on the JSON flow.
> >
> > Please correct anything I get wrong.
> >
> > The openID Connect defines a relation of
> http://openid.net/specs/connect/issuer
> >
> > WF allows for a JSON host-meta that takes two parameters, "resource" and
> "rel"
> >
> > An example request and response (line-brakes for readability)
> >
> > GET /.well-known/host-meta.json
> >      ?resource=[e-mail]
> >      &rel=http%3A%2F%2Fopenid.net%2Fspecs%2Fconnect%2F1.0%2Fissuer
> HTTP/1.1
> >  Host: example.com
> >
> >    HTTP/1.1 200 OK
> >
> >    Access-Control-Allow-Origin: *
> >    Content-Type: application/json; charset=UTF-8
> >
> >    {
> >      "subject" : "[e-mail]",
> >      "links" :
> >      [
> >        {
> >          "rel" : "http://openid.net/specs/connect/issuer",
> >          "href" : "https://server.example.com"
> >        }
> >      ]
> >    }
> >
> > If the host can't support rewrite rules or scripts the exchange would look
> like:
> >
> > GET /.well-known/host-meta.json
> >      ?resource=[e-mail]
> >      &rel=http%3A%2F%2Fopenid.net%2Fspecs%2Fconnect%2F1.0%2Fissuer
> HTTP/1.1
> >  Host: example.com
> >
> > HTTP/1.1 200 OK
> >    Access-Control-Allow-Origin: *
> >    Content-Type: application/json; charset=UTF-8
> >    {
> >      "expires" : "2012-03-13T20:56:11Z",
> >      "links" :
> >      [
> >        {
> >          "rel" : "lrdd",
> >          "type" : "application/json",
> >          "template" :
> >            "https://example.com/lrdd/?format=json&resource={uri}"
> >        }
> >
> > GET /lrdd/
> >      ?format=json
> >      &resource=[e-mail]
> >  Host: example.com
> >
> > HTTP/1.1 200 OK
> >
> >    Access-Control-Allow-Origin: *
> >    Content-Type: application/json; charset=UTF-8
> >
> >    {
> >      "subject" : "[e-mail]",
> >      "links" :
> >      [
> >        {
> >          "rel" : "http://openid.net/specs/connect/issuer",
> >          "href" : "https://server.example.com"
> >        },
> >        {
> >          "rel" : "http://webfinger.net/rel/avatar",
> >          "href" : "http://example.com/~joe/joe.jpg"
> >        }
> >
> >      ]
> >    }
> >
> > I can't find a template parameter for "rel".  The host-meta spec allows for
> extension but it is missing.
> >
> > What if the server wants to support filtering on rel but can't support it in
> the root for some reason?
> >
> > Is it possible to have a template like:
> > "https://example.com/lrdd/?format=json&resource={uri}&rel={rel}"
> >
> > That simple addition may solve a number of problems for openID.
> >
> > John B.
> >
> >
> >