Re: [Captive-portals] API access and .well-known

[Martin Thomson]

Right, I neglected to mention that option.  Call it (d) link relations.

You might also do the reverse in the API-first arrangement that Tommy
suggests (API at the URL, HTML at the other end of a link relation).
It seems likely that 7710 deployment is scant enough that we would be
free to make this decision without being constrained to deal with
backwards compatibility.

One likely deployment involves the thing that is configured being
different to the thing that ultimately serves the content (for reasons
of sorting out the UE identification, if nothing else), so it's
possible that Adam's suggestion here doesn't add round trips that
weren't already needed.

On Wed, Jan 17, 2018 at 9:44 AM, Adam Roach  wrote:
> [as an individual]
>
> I agree that we should strictly avoid synthesizing URLs in general, and
> should try to avoid .well-known URLs in particular. Sometimes you're forced
> to use .well-known (e.g., when there's literally no way to get a full URL to
> the client), but that doesn't seem to be the case here.
>
>
> On 1/14/18 11:39 PM, Martin Thomson wrote:
>
> a. use .well-known and just provide better justification for it
> b. use content negotiation
> c. find some way to get two URIs, like revising 7710 or finding an
> alternative mechanism (such as the one in RFC 5986)
>
>
> For what it's worth, I don't think (a) is possible -- I don't believe any
> plausible justification text can be put together that explains why other
> approaches are infeasible.
>
> Something else to consider is serving up the HTML portal on the endpoint you
> get from RFC7710, and including a link-relation [RFC5988] header field that
> points to the API; e.g.:
>
>
> HTTP/1.1 200 OK
> Link: ;rel="capport-api"
> Content-Type: text/html
>
>  ...
> [legacy portal page goes here]...
> 
>
>
> Importantly: clients interested only in the API can simply perform a HEAD
> rather than a GET to retrieve the Link information. I'll note that this
> provides a clear extension point if you decide you need yet a third thing to
> be discoverable and/or need different HTTP endpoints for versioning in the
> future. I do note that it requires an additional round trip, similar to the
> redirection approach that has been discussed in conjunction with content
> negotiation. Notably, taking this approach eliminates the need for
> redirects, since the link header can point to any arbitrary URL.
>
> /a

___
Captive-portals mailing list
Captive-portals@ietf.org
https://www.ietf.org/mailman/listinfo/captive-portals

Re: [Captive-portals] API access and .well-known

[Adam Roach]

[as an individual]

I agree that we should strictly avoid synthesizing URLs in general, and 
should try to avoid .well-known URLs in particular. Sometimes you're 
forced to use .well-known (e.g., when there's literally no way to get a 
full URL to the client), but that doesn't seem to be the case here.



On 1/14/18 11:39 PM, Martin Thomson wrote:

a. use .well-known and just provide better justification for it
b. use content negotiation
c. find some way to get two URIs, like revising 7710 or finding an
alternative mechanism (such as the one in RFC 5986)



For what it's worth, I don't think (a) is possible -- I don't believe 
any plausible justification text can be put together that explains why 
other approaches are infeasible.


Something else to consider is serving up the HTML portal on the endpoint 
you get from RFC7710, and including a link-relation [RFC5988] header 
field that points to the API; e.g.:



HTTP/1.1 200 OK
Link: ;rel="capport-api"
Content-Type: text/html

... [legacy portal page goes here]... 




Importantly: clients interested only in the API can simply perform a 
HEAD rather than a GET to retrieve the Link information. I'll note that 
this provides a clear extension point if you decide you need yet a third 
thing to be discoverable and/or need different HTTP endpoints for 
versioning in the future. I do note that it requires an additional round 
trip, similar to the redirection approach that has been discussed in 
conjunction with content negotiation. Notably, taking this approach 
eliminates the need for redirects, since the link header can point to 
any arbitrary URL.


/a

___
Captive-portals mailing list
Captive-portals@ietf.org
https://www.ietf.org/mailman/listinfo/captive-portals

Re: [Captive-portals] API access and .well-known

[Tommy Pauly]

Hi Evert,

I think that all three options that Martin provided implicitly support two 
different URLs ([API-URL] and [HTML-URL] for lack of a better term) that a 
client device could use. I agree that making things very explicit and clear is 
important.

>> a. use .well-known and just provide better justification for it

The reason I suggested a well-known URL was to ensure that we didn’t collide 
with some other URL (like the captive portal landing page) or some other JSON 
that’s not really doing this API. It would be easier to validate that the 
configuration did indeed intend to point to this JSON API. 

Note that in this setup, you would learn about the URL of the Captive Portal 
JSON API as the main entry point for the UE (the discovery coming from either 
7710 or PvD or the like). This is specifically the first URL, [API-URL]. The 
JSON content itself would contain [HTML-URL].

Instead of using a well-known URL here, we could imagine just enforcing that 
the discovered URL MUST be a JSON endpoint that serves up this API.

The benefit of this approach (get [API-URL] first, and follow it to [HTML-URL]) 
is that we pave the way towards more flexibility when we don’t necessarily need 
the [HTML-URL] to do traditional captive portals, but instead can do 
interaction models designed for watch-like devices, or multiple devices that 
don’t ever need a follow-on URL.

>> b. use content negotiation

In this approach, [API-URL] and [HTML-URL] are essentially the same, just with 
different content. I agree with the concern that this is ambiguous. It also has 
the potentially negative effect of tying together the JSON API and traditional 
HTML URL. Yes, you can do redirects, etc, to not be co-located, but this seems 
more prone to configuration error and complexity. 

>> c. find some way to get two URIs, like revising 7710 or finding an
>> alternative mechanism (such as the one in RFC 5986)

I think that this approach is effectively saying that [API-URL] and [HTML-URL] 
are both signaled explicitly in the discovery mechanism. While this avoids the 
problem of ambiguity, it bakes in the notion of a legacy captive portal URL, 
and takes up more space in the discovery mechanism.

I’d vote for some variation on (a), but we can just explain the meaning of the 
URL we discover more clearly, instead of using a well known URL.

Thanks,
Tommy

> On Jan 16, 2018, at 10:16 AM, Evert Pot  wrote:
> 
> On 1/14/18 9:39 PM, Martin Thomson wrote:
>> (see also https://github.com/capport-wg/api/issues/2)
>> 
>> Currently the API draft proposes use of .well-known for finding the
>> API.  Generally speaking, there's a trend toward avoiding use of
>> .well-known except when either:
>> 
>> * it is difficult to configure or provide a full URL, or
>> * the .well-known provides information about the origin as a whole.
>> 
>> In this case, the latter definitely doesn't apply, but I think we
>> should probably discuss the former a little.
>> 
>> The problem we have is that there are really two URLs we care about
>> and 7710 only provides one.  (PvD might provide two URLs, so we don't
>> need to worry about this problem for PvD.)
>> 
>> The old API draft used HTTP method to distinguish the two uses: GET
>> for HTML that you might show to a person; POST for an API.  But the
>> new, leaner API uses GET too, so that's not an option we can use.
>> 
>> HTTP content negotiation is another option here.  It's pretty
>> well-supported on the whole aside from a few wrinkles around caching.
>> I suspect we will find that caching will be infeasible for other
>> reasons (see the other issues on GitHub for a taste of that).  Content
>> negotiation works [1] by having the client send an Accept header field
>> with a new media type (straw man: application/capport+json) and the
>> server would detect this and send back an API response or redirect to
>> the API endpoint.  If this content-type wasn't present, it could send
>> back HTML (or a redirect to a server that does).
>> 
>> Here's the options I see:
>> 
>> a. use .well-known and just provide better justification for it
>> b. use content negotiation
>> c. find some way to get two URIs, like revising 7710 or finding an
>> alternative mechanism (such as the one in RFC 5986)
>> 
>> Tommy notes that this has a drawback in that it forces the web UI and
>> API to be co-located.  I don't think that is necessarily true if you
>> accept that HTTP-level redirects are possible.  Indeed, that is how
>> many enforcement points work today: they terminate a connection
>> locally but then redirect to more capable servers.  Also, using
>> .well-known doesn't really make the resources any less co-located
>> because the origin - and the server - are still the same.
>> 
>> What do folks prefer here?
>> 
>> [1] Content negotiation can use other properties of the request as
>> well, but Accept is common and pretty widely supported.
> We would definitely prefer to see 2 distinct urls here. It makes the least 
> amount of assu

Re: [Captive-portals] UE Identification

[Tommy Pauly]

The WIP is up on GitHub here:

https://github.com/capport-wg/api 

Thanks,
Tommy

> On Jan 16, 2018, at 10:24 AM, David Bird  wrote:
> 
> Do we have a preliminary draft of the API yet?
> 
> Requirements, purpose, whatnot...
> 
> On Mon, Dec 4, 2017 at 12:39 PM, David Bird  > wrote:
> Looking forward to it!
> 
> 
> On Mon, Dec 4, 2017 at 12:35 PM, Tommy Pauly  > wrote:
> Darshak Thakore and I are now the editors of the API document, and will be 
> posting a new version of the document hopefully soon that addresses the 
> discussions from the previous two IETF meetings. This definition will be a 
> lot simpler, and should make it clearer how to interact with the ICMP path. 
> 
> Thanks,
> Tommy
> 
> 
>> On Dec 4, 2017, at 9:11 AM, David Bird > > wrote:
>> 
>> I will also point out that the API is not only ill-defined, it doesn't have 
>> editors... right?
>> 
>> On Mon, Dec 4, 2017 at 9:08 AM, David Bird > > wrote:
>> These are good questions for the group to consider and provide feedback on...
>> 
>> While doing so, also consider the fact that the "The basic problem is that 
>> the enforcement point and API are two different entities." is a problem of 
>> our own creation in an effort to support an API that we haven't clearly 
>> defined.
>> 
>> I suggest rethinking the problem, let the extra ICMP semantics sink in, and 
>> consider the fact that we could achieve similar use-cases (if not identical, 
>> even more use-cases) without the above "basic problem" ... 
>> 
>> The use-cases I speak of specially are:
>> 
>> - A way to better identify captivity in the network and feedback (on a need 
>> to know basis) of what resources are allowed in the walled garden.
>> - A non-redirect (non-flow terminating) way of notifying of pending session 
>> interruptions or otherwise suggesting a portal visit.
>> - A deployment model that doesn't put huge requirements on systems 
>> integrations and installers.
>> 
>> 
>> On Sun, Dec 3, 2017 at 11:53 PM, Martin Thomson > > wrote:
>> Thanks Kyle for the summary of the discussion.
>> 
>> The chairs would like to focus your attention on the issue of User
>> Equipment identification.  The basic problem is that the enforcement
>> point and API are two different entities.  They might also need to
>> talk about the UE with other entities (RADIUS servers, logging
>> systems, payment systems, and all sorts of backend systems).
>> 
>> How should the UE be identified?
>> 
>> We had a great discussion about this in Singapore and it's the view of
>> the chairs that there was no consensus for defining a set of UE
>> identifiers for explicit use in the protocols.  There were a few
>> reasons for this. One was that it would be difficult to find a set of
>> identifiers that would work for all deployments.  Also, allowing the
>> UE to include identifiers would increase the risk that the UE spoofs
>> those identifiers.
>> 
>> The two options that were discussed at length both involved having the
>> UE identified implicitly.  That is, some property of the packets that
>> arrive at the enforcement point would be used to identify the UE.  The
>> concern being that the identifier(s) were not subject to spoofing.
>> MAC, IP, or the circuit on which the packets arrive might all be
>> acceptable.
>> 
>> There was some discussion about how to manage consistent
>> identification between API and enforcement.  From the discussion, we
>> appear to have two options:
>> 
>> 1. Identify the UE at the API the same way that it is identified at
>> enforcement.  API and enforcement would have to agree on the
>> identifier they use.  This would also constrain deployments so that
>> the API has to be located on the network in a position where
>> spoofing identifiers isn't possible.
>> 
>> 2. Have the enforcement device pass an identifier (a "session ID") to
>> the UE for use with the API.  The enforcement would probably use an
>> ICMP extension to pass this information back.  This would need to be
>> authenticated, so that the UE couldn't generate a valid identifier.
>> There was plenty of discussion about that, but the short summary is
>> that this is possible if we want to have it happen.
>> 
>> It seems like there is some sense that the first option was preferred.
>> We'd like to get a sense of the list here.  Which of these options is
>> preferable, and why?
>> 
>> ___
>> Captive-portals mailing list
>> Captive-portals@ietf.org 
>> https://www.ietf.org/mailman/listinfo/captive-portals 
>> 
>> 
>> 
>> ___
>> Captive-portals mailing list
>> Captive-portals@ietf.org 
>> https://www.ietf.org/mailman/listinfo/captive-portals 
>> 

Re: [Captive-portals] API access and .well-known

[Evert Pot]

On 1/14/18 9:39 PM, Martin Thomson wrote:

(see also https://github.com/capport-wg/api/issues/2)

Currently the API draft proposes use of .well-known for finding the
API.  Generally speaking, there's a trend toward avoiding use of
.well-known except when either:

* it is difficult to configure or provide a full URL, or
* the .well-known provides information about the origin as a whole.

In this case, the latter definitely doesn't apply, but I think we
should probably discuss the former a little.

The problem we have is that there are really two URLs we care about
and 7710 only provides one.  (PvD might provide two URLs, so we don't
need to worry about this problem for PvD.)

The old API draft used HTTP method to distinguish the two uses: GET
for HTML that you might show to a person; POST for an API.  But the
new, leaner API uses GET too, so that's not an option we can use.

HTTP content negotiation is another option here.  It's pretty
well-supported on the whole aside from a few wrinkles around caching.
I suspect we will find that caching will be infeasible for other
reasons (see the other issues on GitHub for a taste of that).  Content
negotiation works [1] by having the client send an Accept header field
with a new media type (straw man: application/capport+json) and the
server would detect this and send back an API response or redirect to
the API endpoint.  If this content-type wasn't present, it could send
back HTML (or a redirect to a server that does).

Here's the options I see:

a. use .well-known and just provide better justification for it
b. use content negotiation
c. find some way to get two URIs, like revising 7710 or finding an
alternative mechanism (such as the one in RFC 5986)

Tommy notes that this has a drawback in that it forces the web UI and
API to be co-located.  I don't think that is necessarily true if you
accept that HTTP-level redirects are possible.  Indeed, that is how
many enforcement points work today: they terminate a connection
locally but then redirect to more capable servers.  Also, using
.well-known doesn't really make the resources any less co-located
because the origin - and the server - are still the same.

What do folks prefer here?

[1] Content negotiation can use other properties of the request as
well, but Accept is common and pretty widely supported.
We would definitely prefer to see 2 distinct urls here. It makes the 
least amount of assumptions, and gives the most amount of flexibility.


Evert

___
Captive-portals mailing list
Captive-portals@ietf.org
https://www.ietf.org/mailman/listinfo/captive-portals