> The issues there are essentially whether users can consent in
> real time
I find the consent issue particularly interesting (bear with me...). One
of the benefits that we get from the browser-bound bindings is the
opportunity to interrogate the user about things like consent.
In Moonshot, the SAML messages are bound to a back-channel. Therefore,
we can't apply the same kind of stratgy for obtaining consent. But, in
many scenarios, consent is still necessary. How should we address this?
Given that we're assuming the existence of a supplicant for driving
identity selection and authentication, I'm also inclined to use the
supplicant for consent. How would we do this? There's probably a lot of
ways to model this, but I've been looking at the Liberty Alliance
Interaction Service. As the name suggests, this defines a way for
entities to pose questions to users. In brief, the supplicant and the
user's IdP establish an HTTP connection; when an attribute request
message hits the IdP, it could optionally send an interaction service
message to the supplicant, which would construct a form in the
supplicant for the user to complete. The user makes a decision, and the
supplicant sends it back and the IdP would act on this information.
We could do a lot of interesting things; for example, the supplicant
could maintain a local consent policy database, or it could sync these
with the IdP's own consent management database and delegate the consent
decision to the IdP.
The Interaction Service is a fairly simple spec, but there are probably
other approaches we should also consider. Ideas welcome!
josh.
JANET(UK) is a trading name of The JNT Association, a company limited
by guarantee which is registered in England under No. 2881024
and whose Registered Office is at Lumen House, Library Avenue,
Harwell Science and Innovation Campus, Didcot, Oxfordshire. OX11 0SG
|