RE: [saml-dev] Réf. : [saml-dev] Re: Réf. : Re: [saml-dev] Réf. : RE: [saml-dev] AttributeQuery : why SOAP binding ?

Title: RE: [saml-dev] R嶨. : [saml-dev] Re: R嶨. : Re: [saml-dev] R嶨. : RE: [saml-dev] AttributeQuery : why SOAP binding ?

Sorry Scott, I missed an earlier part of the email thread discussion.  You are correct that our requirement is to dynamically request attributes at authentication time. 

 

If something was written and accepted for requesting specific attributes within the <AuthnRequest> i.e. an approach like an <RequestedAttribute> element.  Would you expect that this would be incorporated within the SAML 2 specification and schema or would this be a use of the existing extensions element in the <AuthnRequest>?

 

Regards

Ben

 

From: Scott Cantor [mailto:]
Sent: Mon 17/11/2008 16:11
To: Ben Yeoman
Cc: 
Subject: RE: [saml-dev] R嶨. : [saml-dev] Re: R嶨. : Re: [saml-dev] R嶨. : RE: [saml-dev] AttributeQuery : why SOAP binding ?

> We have exactly the same requirement for "dynamically" obtaining
information
> from an IdP with user consent at the IdP here in New Zealand.

I don't see how it's the same if your problem can be solved at
authentication time and theirs apparently can't. I agree with Valerie that
if the requirement is to ask for information after login, it's silly to
artificially perform another authentication to get the information.

> I believe that submissions are currently in progress to the SAML 2
technical
> expert committee for a mechanism within the specification to permit the
> dynamic requesting of information within the <AuthnRequest>.  I am not
aware
> of any timeframe or the whether the submissions will be accepted, but I
hope
> this helps.

There's no timeframe because the person that offered to draft something
hasn't done so. There is no submission that uses the required conventions
and follows the norms that would be acceptable in an approved extension.

> Other potential options (but not really recommended) could involve
> specifying the required attributes as a String in the
> <RequestedAuthnContext>.

Obviously, that doesn't make much sense. We have an extension point, that's
what you need to use if you develop something yourself.

> The AttributeConsumerServiceIndex is another
> option, but is a fairly indirect mechanism.

It's no different than using a WS-SecurityPolicy document with Cardspace.

> As a last resort you could
> consider the use of SAML <Extensions> in the <AuthnRequest>, but I don't
> know if that would suit your model either?

I'm not sure if you're clear on this, but if something "official" gets
drafted, that's what it will be. There is no other place to do it (within an
AuthnRequest).

But Valerie's problem is different, and I would agree that using a query
through the browser probably makes more sense.

-- Scott