[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [saml-dev] Réf. : [saml-dev] Re: Réf. : Re: [saml-dev] Réf. : 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]