El 11/07/13 03:43, Sam Hartman escribió:
> In this case I think you should send a response rather than encrypted
> assertion
I agree.
And in this case I think it would be a more elegant solution if the
client specifies (AuthnQuery, AttributeQuery, AuthzDeciscionQuery) the
kind of assertion to be returned by the idP . I think current draft
version points out a MAY in this case. It also would help the idP to do
not spend time processing SAML data if the client does not support it.
regards, Gabi.
>
> "Cantoris Scott" <[email protected]> wrote:
>> On 7/10/13 6:33 PM, "Sam Hartman" <[email protected]>
>> wrote:
>>> seems to me that if you have a way of getting a credible key for the
>> SP,
>>> then it's fine to use it.
>>>
>>> If you encrypt in a key that the other party doesn't know, interop may
>>> be impacted. This is probably unsurprising:-)
>> I have no issue with allowing it, I just wanted to note it as another
>> case
>> where the object "at hand" might not be <saml:Assertion>. I also don't
>> know if it warrants defining a different RADIUS attribute to carry it.
>>
>> -- Scott
>
>
> _______________________________________________
> abfab mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/abfab
--
--------------------------------------------------------------
Gabriel López Millán
Departamento de Ingeniería de la Información y las Comunicaciones
University of Murcia
Spain
Tel: +34 868888504
Fax: +34 868884151
email: [email protected]
_______________________________________________
abfab mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/abfab
