Re: [Captive-portals] Remediation url for CAPPORT

Remi NGUYEN VAN <reminv@google.com> Tue, 14 January 2020 02:00 UTC

Return-Path: <reminv@google.com>
X-Original-To: captive-portals@ietfa.amsl.com
Delivered-To: captive-portals@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C894912006F for <captive-portals@ietfa.amsl.com>; Mon, 13 Jan 2020 18:00:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.499
X-Spam-Level:
X-Spam-Status: No, score=-17.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rd4f6BbuTwGv for <captive-portals@ietfa.amsl.com>; Mon, 13 Jan 2020 18:00:30 -0800 (PST)
Received: from mail-il1-x12a.google.com (mail-il1-x12a.google.com [IPv6:2607:f8b0:4864:20::12a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E49FC12001B for <Captive-portals@ietf.org>; Mon, 13 Jan 2020 18:00:29 -0800 (PST)
Received: by mail-il1-x12a.google.com with SMTP id t2so10026917ilq.9 for <Captive-portals@ietf.org>; Mon, 13 Jan 2020 18:00:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ynvSuBUcq0xp3JkGf5atYMVWVM+T9iRji1Nbmb63ltk=; b=ahsAils4wnNMxgmJxSHHYEKuL3dGfy12+0VuDKeYnnKjqfl4U/uISxGXXNA7DKnfm9 oId3XS0tg6USl51eR5mHGRf++72o7f+wZBwQr6BUp4Xqn9r242+MtqPBDRbqL6twCEdF DQCyHlhWUfJ00L34AZ2Z4+LDk9j45d6fhc5YcamMN3np7Bcr5ZYydO5aNJBHlNTduHA1 VXQrAw8/f82Ggu0gbfTgxSmd31RmzzJCUTLDKAZLe0sVUYimhMthxE5UECCBgljngi3h Ngq2JqBq6SyvLmO9fiRD1LGLhGVn55xrRHE34aIE6/j9cw0qM2xFwzJfmsFxuz6cHtbN 5oOg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ynvSuBUcq0xp3JkGf5atYMVWVM+T9iRji1Nbmb63ltk=; b=Py26xDpwlI+DbEATEBnzKbNAHe3aG095QHo2HgwEkQZX6jmeruDmwFhtkpavNZwkc0 GzUadAieYomIlwKiB8YhzFzvyb0XuMucs6XI7CiQaoqfdILPIG6H+2LUvL0FEI6nYZM3 oo2JFF76Uhc46kn4k8oZdKZOwCVKo1XWoV2Qqm4fyVjclcYTxZu+KGnN0908bnXQDrWd MON7igkA9pxLPGmH7N0bMke7ykUygK9Wwzm6SF0OniA/ECPrU1Rd5r4ecTMV8lwvRUYX nNYVccbzefn/crmGA7Llpd1gBouVqZLQVeP7p+TKoaeAe79b4Q0j5SMBnFOoAkElhPXw EPKA==
X-Gm-Message-State: APjAAAW57UEXfxPxjWanj6YiybarevwsNH0MCNr1gY3inISCNZUptDmm C0IBbEOZC/0NSs0mH4BdPhqZdjFSOBAT02oioV2l3g==
X-Google-Smtp-Source: APXvYqxEKKsp1ETCAvJFhZX9MMDMmO6fnuzYDTNdYQ1iyYW7RhRKyekz222cN54MrtBJV2Vf4pJfPJzZrMysdenvP+w=
X-Received: by 2002:a92:8d8e:: with SMTP id w14mr1356536ill.187.1578967228965; Mon, 13 Jan 2020 18:00:28 -0800 (PST)
MIME-Version: 1.0
References: <CAKMty=Ks0j6dxPvsDHTpWBCrujihCe7Yzsb4zaV5SkRfh8fx9Q@mail.gmail.com> <CAKxhTx_uaZVFs4VhM+nro61XxTjPtwZ+pZ_gsJtNQXiNHtf2vQ@mail.gmail.com> <CAMGpriX1ct9y53HZ2FtbK00TfVm3uNRFMwYQW0Wb_18XoXjFJw@mail.gmail.com> <CAKMty=KhYr4XfJWzXeBiod1oiyG-qVp7-ANKJaZF1-_nPZhrTw@mail.gmail.com> <CAAedzxocTUhQ-z+_Cpz8PhG=o3CR4aZHOGddngiEjZ1HZChP1A@mail.gmail.com> <D00FBAF2-3825-4435-8426-10C300E491F2@apple.com>
In-Reply-To: <D00FBAF2-3825-4435-8426-10C300E491F2@apple.com>
From: Remi NGUYEN VAN <reminv@google.com>
Date: Tue, 14 Jan 2020 11:00:17 +0900
Message-ID: <CAKxhTx9g3WrKM=BP2fifv08CVcMrZvhuvnZjapb3ugN=WX1fhg@mail.gmail.com>
To: Tommy Pauly <tpauly=40apple.com@dmarc.ietf.org>
Cc: Erik Kline <ek@loon.com>, Heng Liu <liucougar@google.com>, Erik Kline <ek.ietf@gmail.com>, captive-portals <Captive-portals@ietf.org>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="000000000000d23f84059c0ff425"
Archived-At: <https://mailarchive.ietf.org/arch/msg/captive-portals/PdTbxQAT1v21OL8_6Lr1OG91uEw>
Subject: Re: [Captive-portals] Remediation url for CAPPORT
X-BeenThere: captive-portals@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussion of issues related to captive portals <captive-portals.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/captive-portals>, <mailto:captive-portals-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/captive-portals/>
List-Post: <mailto:captive-portals@ietf.org>
List-Help: <mailto:captive-portals-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/captive-portals>, <mailto:captive-portals-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 14 Jan 2020 02:00:33 -0000

If we show prompts to the user shortly before the session expires, we'd
like to make sure that we can redirect them to some page where they can fix
the problem, instead of landing on a page saying "you're logged in". The
user-portal-url would work fine with a remediation-supported boolean for
that purpose; having a separate URL gives additional flexibility to the
access point operator, but from the point of view of the client I think
both are fine.

Cheers,

Remi


On Tue, Jan 14, 2020 at 10:02 AM Tommy Pauly <tpauly=
40apple.com@dmarc.ietf.org> wrote:

> I have a similar initial reaction to Erik's. Adding another URL that
> effectively is just another user portal, but meant to be used at certain
> times, adds a lot of complexity. I'm certainly not ruling out adding such a
> key as need arises, but I'd hesitate to make it part of the initial set.
>
> Particularly, if we start seeing the "venue URL" be the main landing page
> we redirect people to once they're logged it, it kind of makes sense to let
> the user portal be the status/remediation/payment page.
>
> Tommy
>
> On Jan 13, 2020, at 4:06 PM, Erik Kline <ek@loon.com> wrote:
>
>
>
> On Mon, 13 Jan 2020 at 15:26, Heng Liu <liucougar=
> 40google.com@dmarc.ietf.org> wrote:
>
>> On Sun, Jan 12, 2020 at 2:34 PM Erik Kline <ek.ietf@gmail.com> wrote:
>>
>>> Why should this different from the user-portal-url?  It seems to me that
>>> either the user-portal-url would remediation UI elements or it wouldn't.
>>>
>> Some CP vendors want to specify a different URL specifically tailored for
>> remediation of a session. By providing a 3rd URL, we can accommodate this
>> use case.
>>
>
> If the remediation URL is available but the user (somehow) navigates to
> the user-portal-url, what do they see?
>
>
>>
>>> With this 3rd URL, if the bytes/time does expire should the OS try to
>>> launch an interaction the remediation URL and then fallback to the user URL
>>> if it failed to load?  In which case, why not just leave all interaction
>>> with the user-portal-url?
>>>
>> if a remediation URL is present, and if it fails to load for whatever
>> reason, no need to fallback to user portal URL: CP vendor should make sure
>> the remediation URL is working properly (this is similar to user-portal url
>> should work properly, if not, there is no other way for user to clear a CP)
>>
>
> I guess I'm just trying to be mindful of one person's flexibility is
> another person's complexity.  I think this just doubles the number of URLs
> that the CP vendor needs to make sure function correctly.
>
> If the vendor doesn't implement a means to extend your session without
>>> completely shutting everything down and forcing to the user to restart the
>>> interaction flow anew, I could see that an OS would not want to bother the
>>> user with an interaction where they couldn't actually do anything useful.
>>> But that might suggest a boolean capability, rather than a new URL
>>> (remediation-supported={true|false})?
>>>
>> A boolean field could also be a positive signal to notify UE that
>> remediation is possible, but this would prevent CP vendors from using
>> different URLs for remediation.
>>
>> (As mentioned in the initial thread, this URL approach is also taken by
>> the Passpoint release 2.0 spec to signal remediation process.)
>>
>> regards,
>> Heng
>> _______________________________________________
>> 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
>
>
>