>
>>> Yes, but it wouldn't prove that you got either one from somebody you
>>> trusted and not some arbitrary interloper.
>>
>> Sure, but we can authenticate the binding used to obtain the artifact
>> to obtain that assurance.
> How? The artifact is passed through the client, so there's no way
> for the
> message's intended recipient to authenticate it from the message/
> artifact
> issuer.
Ok, I should explain that I'm asking these questions in the context of
a new binding that I'm working on. In this case, I'm working on the
assumption that the thing-in-the-middle can be trusted by the SAML
requester to do the authentication.
(I don't believe that SAML has a generic term for the thing-in-the-
middle that is the user agent in the HTTP Artifact Binding in the
context of artifact resolution, but please correct me if I am wrong)
>> I originally thought there was a violation because I got badly
>> confused. Where is the violation now? The callback does not require
>> authentication...?
>
> The profile says the SAML responder MUST authenticate itself to the
> SAML
> requester, doesn't it?
So it does. It does provide some flexibility in how this is achieved:
"...or using a binding-specific mechanism". However, I assume that
this is meant to refer to the binding used by the Artifact Resolution
Protocol (e.g., SOAP binding), rather than the binding-in-development
used to transport the artifact to the SAML requester.
I believe that I can achieve equivalent assurances by providing the
message-hash evidence to the SAML requester using the binding-in-
development, and comparing this to whatever it happens to resolve
using the ARP binding (assuming we trust the thing-in-the-middle to
authenticate the SAML responder). However, I don't think it is
reasonable to describe this as authentication "...using [a] binding-
supported mechanism".
I think I'm stuck. Do you see any possible strategies for resolving
this?
(I want to avoid authenticating the SAML requester to the SAML
responder, and vice versa; but it's fine for the thing-in-the-middle
to authenticate itself to both parties).
josh.
