[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: "binding" assertions to business payloads
One issue discussed in the bindings group con-call this past week is that of providing an authentic binding between assertions and business payloads. The following scenario is driven off use-case 3 from the requirements document: End-user Ravi utilizes an authentication service and obtains assertions ("Ravi is an employee of Company X at the supervisor level") which he packages with a business payload ("Buy 100 paper clips") to create a composite package. One way to ensure authenticity is to have Ravi sign the composite package with his private key. When the recipient receives the package, the recipient can check to see if the package has been tampered with. If not, the recipient can scrutinize the assertions and appropriately process the business payload. The concern here is with a MITM attack: attacker John intercepts the package and packages the assertion with a completely different payload ("Buy 1000 computers"), signs the composite package and forwards it to the recipient. In order to avoid an MITM attack, it seems necessary that the assertion should include Ravi's public key (or more generally <dsig:keyinfo>) within the assertion. When the composite package arrives at the recipient, she can validate the signature using the public key found within the assertion. This ensures that only the original ``holder'' of the assertion could have bound it to the payload. It is not clear to me how this is handled within the current assertion structure. Obviously, this issue is fairly key to the bindings group; some clarification is required in this space. - prateek
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC