> define an AuthnRequest Extension to allow
> for
> tunnelling Attributes to use as a query
can you explain a bit more about this please? What do you mean by
"tunnelling"?
thanks,
Alistair
--
mov eax,1
mov ebx,0
int 80h
>> So, for example, a self-query for attributes could ask for two
>> holder-of-key SubjectConfirmations, one binding the principal's key
>> and the other binding an SP's key, so that the SP could forward the
>> assertion to another SP. (I know I'm stepping on a land mine here,
>> but what the heck :)
>
> Yes, I think that's exactly what it would be for. If you look at WS-Trust,
> it doesn't know anything about the kind of assertion you might be able to
> ask for, so I think it's reasonable to have the ability in SAML to get
> just
> an attribute assertion but still have some of the same security
> decoration.
>
> There's no rule that says you can't get back an AuthnStatement from a
> query
> either, so I was sort of imagining that you could query for attributes,
> and
> the means of authentication could dictate what the AuthnStatement
> contained.
>
> You don't have some of the flexibility as in the AuthnRequest (like asking
> for Conditions), but some of it is there.
>
> I think it's past time to just define an AuthnRequest Extension to allow
> for
> tunnelling Attributes to use as a query though. If I'd known that POST was
> going to be so accepted as a binding for SSO requests, I'd probably just
> have included it in the schema anyway. I just didn't think it would fit
> well
> in a Redirect.
>
> -- Scott
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:
>
>
