Return-Path: Received: (from root@localhost) by example.com (8.11.6/8.11.6/SuSE Linux 0.5) id h4CMt1U02501 for root; Mon, 12 May 2003 17:55:01 -0500 Date: Fri, 26 Feb 2010 23:58:57 -0000 MIME-Version: 1.0 Message-Id: <200305122255.h4CMt1U02501@example.com> To: abfab@ietf.org Content-Type: text/plain; charset="us-ascii" > 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 Return-Path: Received: (from root@localhost) by example.com (8.11.6/8.11.6/SuSE Linux 0.5) id h4CMt1U02501 for root; Mon, 12 May 2003 17:55:01 -0500 Date: Fri, 26 Feb 2010 23:55:40 -0000 MIME-Version: 1.0 Message-Id: <200305122255.h4CMt1U02501@example.com> To: abfab@ietf.org Content-Type: text/plain; charset="us-ascii" > 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 Return-Path: Received: (from root@localhost) by example.com (8.11.6/8.11.6/SuSE Linux 0.5) id h4CMt1U02501 for root; Mon, 12 May 2003 17:55:01 -0500 Date: Fri, 26 Feb 2010 23:08:28 -0000 MIME-Version: 1.0 Message-Id: <200305122255.h4CMt1U02501@example.com> To: abfab@ietf.org Content-Type: text/plain; charset="us-ascii" > > 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 Return-Path: Received: (from root@localhost) by example.com (8.11.6/8.11.6/SuSE Linux 0.5) id h4CMt1U02501 for root; Mon, 12 May 2003 17:55:01 -0500 Date: Fri, 26 Feb 2010 14:38:21 -0500 MIME-Version: 1.0 Message-Id: <200305122255.h4CMt1U02501@example.com> To: abfab@ietf.org Content-Type: text/plain; charset=us-ascii 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