Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "Relying Party Security Policy"
m |
m |
||
| Line 3: | Line 3: | ||
1. The user requesting a resource from the relying party. | 1. The user requesting a resource from the relying party. | ||
| − | 1. Relying party making available to the user an 'assertion request' describing what information the user | + | 1. Relying party making available to the user an 'assertion request' describing what information the user needs to provide in order to get access to the resource. The assertion request will be derived from the access control policy of the relying party (in the simplest case the assertion request and the access control policy will be identical maybe |
| − | + | except for being described in different languages). | |
| − | + | ||
| − | + | ||
1. The user matches the 'asserion request' with the set of assertions about her that are endorsed by some party | 1. The user matches the 'asserion request' with the set of assertions about her that are endorsed by some party | ||
| − | + | (including herself in case of self signed statements) and making a selection which (set of) assertion(s) to send to | |
| − | + | the relying party. | |
1. The user sending the relying party the selected assertion(s) plus supportive evidence. | 1. The user sending the relying party the selected assertion(s) plus supportive evidence. | ||
1. The relying party receiving the assertion(s) and supportive evidence, veryfing the correctness of the evidence w.r.t. the assertions, and matching the provided assertion with | 1. The relying party receiving the assertion(s) and supportive evidence, veryfing the correctness of the evidence w.r.t. the assertions, and matching the provided assertion with | ||
Revision as of 09:25, 25 October 2006
Consider the following scenario where a relying party requies a user to send some information about her. This involves the following steps:
1. The user requesting a resource from the relying party. 1. Relying party making available to the user an 'assertion request' describing what information the user needs to provide in order to get access to the resource. The assertion request will be derived from the access control policy of the relying party (in the simplest case the assertion request and the access control policy will be identical maybe except for being described in different languages). 1. The user matches the 'asserion request' with the set of assertions about her that are endorsed by some party (including herself in case of self signed statements) and making a selection which (set of) assertion(s) to send to the relying party. 1. The user sending the relying party the selected assertion(s) plus supportive evidence. 1. The relying party receiving the assertion(s) and supportive evidence, veryfing the correctness of the evidence w.r.t. the assertions, and matching the provided assertion with
This scenarios
This is a page dedicated to a language to specify a token-request made by a relying party, i.e., to specify what information the user needs to supply to get access to some resource.
Language format: to be determined could be homegrown, use RDF so that it maps into data model. Similar language to request tokens from issuer. Also relates to WS-policy-constrains [1]
Elements that need to be expressed:
- type of i-card
- attribute
- issuer
- recipient
- in encrypted form (under what key)
- in committed form
- arbitrary statement over attributes (e.g., age < 18)
- logical formulas over terms (AND, OR)
- backing of statement (self-signed, passport checked, .....)
- data handling policy (privacy policy stating things like purpose, retention time etc)