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

[Martin Thomson]

On Fri, Jan 19, 2018 at 9:33 AM, Adam Roach  wrote:
> Sure, either in a 3xx response; or, if we're using Link: relations, those
> URLs can vary based on the client. If you want to get fancy about it, you
> can even have your DHCP server hand out different URLs in the RFC7710 field.
> There are a lot of ways to deal with multi-tenancy.

Adam is correct.  Note that DHCP offers the possibility of per-client
configuration, which is something not available with a RA.

Note also that if you believe it necessary to provide the client with
an identifier using any of these opportunities, you need to
authenticate it later, lest the client switch it out on you.  This
might not give the client the ability to piggy back on top of another
client's access, but it might lead to privacy violations.

___
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]

On 1/18/18 4:18 PM, Michael Richardson wrote:

Adam Roach  wrote:
 > 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.

Is it reasonable for different enforcements points to return different URLs
to different clients?  If so, that solves much of the multi-tenancy problems,
and I guess I recant some of my previous message.


Sure, either in a 3xx response; or, if we're using Link: relations, 
those URLs can vary based on the client. If you want to get fancy about 
it, you can even have your DHCP server hand out different URLs in the 
RFC7710 field. There are a lot of ways to deal with multi-tenancy.



I'd still like to register a /.well-known value as a suggestion.


Why?

/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]

On 1/18/18 4:15 PM, Michael Richardson wrote:

I think that we need the 7710 mechanism to get the HOST part, and that the
URL part SHOULD be .well-known/blah, but MAY be something else.



No, please don't. That's very much *not* what .well-known is meant for. 
See RFC 5785, section 1.1.


/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

[Michael Richardson]

Adam Roach  wrote:
> 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.

Is it reasonable for different enforcements points to return different URLs
to different clients?  If so, that solves much of the multi-tenancy problems,
and I guess I recant some of my previous message.

I'd still like to register a /.well-known value as a suggestion.

--
Michael Richardson , Sandelman Software Works
 -= IPv6 IoT consulting =-





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

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

[Michael Richardson]

Tommy Pauly  wrote:
> 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.

+1

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

I think that we need the 7710 mechanism to get the HOST part, and that the
URL part SHOULD be .well-known/blah, but MAY be something else.


--
Michael Richardson , Sandelman Software Works
 -= IPv6 IoT consulting =-





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