[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Captive-portals] A view from a WiFi provider on captive portal requirements, challenges and improvements





On 19 April 2017 at 02:18, Dave Dolson <[email protected]> wrote:

Regarding the AP/client identification, this is the reason I suggested in an earlier email,

https://mailarchive.ietf.org/arch/msg/captive-portals/RPwEIuLlW6ZSLmEyaqfxgDrF88Q

 

"

Posting to the create_href:

POST http://<server>/capport/sessions (Accept: application/json)

{ "identity": "<USERNAME>"}

 

The USERNAME could be DHCP option-12 value or MAC address or ?  

"

 

I didn’t know exactly what this identity should be. Maybe multiple identity options are useful.


Or an https://tools.ietf.org/html/rfc7542 style Network Access Identifier.

This may be straying too far into solutioneering too soon, but one outcome of a captive portal login/auth process might be the negotiation of an NAI for the UE to present in future session interactions (renewal and reattachment).

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature