To: [email-masked]
Date: Fri, 26 Feb 2010 23:58:57 -0000

> whether requirements from the service's end=20
> vary dynamically.

When you say dynamically, do you mean faster than requirements can be
managed out-of-band?

josh.

JANET(UK) is a trading name of The JNT Association, a company limited
by guarantee which is registered in England under No. 2881024=20
and whose Registered Office is at Lumen House, Library Avenue,
Harwell Science and Innovation Campus, Didcot, Oxfordshire. OX11 0SG

Date: Fri, 26 Feb 2010 23:55:40 -0000
To: [email-masked]
> The issues there are essentially whether users can consent in=20
> 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=20
and whose Registered Office is at Lumen House, Library Avenue,
Harwell Science and Innovation Campus, Didcot, Oxfordshire. OX11 0SG

Date: Fri, 26 Feb 2010 23:08:28 -0000
To: [email-masked]
> > Here's what I think we need out of the SAML request. I think it=20
> > provides a place for S to indicate what attributes it=20
> needs. First,=20
> > is this correct? Secondly, is there anything else that our=20
> particular=20
> > use cases get out of a SAML request?
>=20
> I think the way to answer that is best handled by starting=20
> with what you want to get in return, and then in parallel=20
> setting out the assumptions made about what knowledge of the=20
> user exists between S, the entity making the request (if it's=20
> not S), and the IdP.
>=20
> The main thing we have to do is determine the "fit" between=20
> those answers and the existing protocols in SAML.

At the risk of generalising, I think it is interesting to consider
whether we can extrapolate from today's Web SSO practices, particularly
as in the use-cases we're not using SAML for authentication (where we
might care about LoA etc); only as a source of attributes. The SAML IdP,
consequently, says what goes and what doesn't and the request is moot.

josh.

JANET(UK) is a trading name of The JNT Association, a company limited
by guarantee which is registered in England under No. 2881024=20
and whose Registered Office is at Lumen House, Library Avenue,
Harwell Science and Innovation Campus, Didcot, Oxfordshire. OX11 0SG

Date: Fri, 26 Feb 2010 14:38:21 -0500
To: [email-masked]
SAML request that goes from S to TAC and thus to C's IDP. During that
discussion I realized that I don't have a clear idea of what we're using
the SAML request to accomplish.

Here's what I think we need out of the SAML request. I think it
provides a place for S to indicate what attributes it needs. First, is
this correct? Secondly, is there anything else that our particular use
cases get out of a SAML request?

--Sam