Contract No.: 285248 Strategic Objective
Download 1.78 Mb.
|
- Navigate this page:
- 13.6.1Credential Issuance
- 13.6.2Token Presentation
13.6Main InteractionsWe describe below the interfaces that are exposed by the Privacy GE (through the ABC Engine) for the two main scenarios: issuance of a credential and authentication via a presentation token. The full specification of the Privacy GE can be found in the Open Specifications. The APIs are described in an object-oriented fashion as a list of methods that take input parameters of certain types and that produce an output of a certain return type. The data types of the input and return types either refer to XML artifacts as defined in the Open Specifications, or to simple XML Schema datatypes such as boolean or string. 13.6.1Credential IssuanceCredential issuance is a multi-round interactive protocol between the Issuer and the User, at the end of which the User obtains a new credential. In the simplest setting, an Issuer knows all attribute values and issues credentials “from scratch”, i.e., without relation to any existing Privacy-ABCs already owned by the Users. Prior to the issuance, the Issuer may have obtained and verified all attribute values through an out-of-band process. In a more advanced setting, Privacy-ABCs can be issued so that certain features of the new credential are “carried over” from credentials that the User already owns, without the Issuer being able to learn the carried-over information in the process. To this end, the Issuer provides the User with an issuance policy, which consists of a presentation policy and a credential template. The sequence of a credential issuance interaction is illustrated in Figure 2. 
Figure 2: Credential Issuance. User side issuanceProtocolStep(m:IssuanceMessage) → IssuanceMessage or CredentialDescription This method performs one step in an interactive issuance protocol. On input an incoming issuance message m obtained from the Issuer, it either returns the outgoing issuance message that is to be sent back to the Issuer, or returns a description of the newly issued credential at successful completion of the protocol. In the former case, the Context attribute of the outgoing message has the same value as that of the incoming message, allowing the Issuer to link the different messages of this issuance protocol. Issuer side initIssuanceProtocol(ip:IssuancePolicy, atts:Attribute[]) → (IssuanceMessage, boolean) This method is invoked by the Issuer to initiate an issuance protocol based on the given issuance policy ip and the list of attribute type-value pairs atts to be embedded in the new credential. It returns an IssuanceMessage that is to be sent to the User. The IssuanceMessage contains a Context attribute that will be the same for all message exchanges in this issuance protocol, to facilitate linking the different flows of the protocol. In case of an issuance “from scratch”, i.e., for which the User does not have to prove ownership of existing credentials or established pseudonyms, the given issuance policy ip merely specifies the credential specification and the issuer parameters for the credential to be issued. In this case, the returned issuance message is the first message in the actual cryptographic issuance protocol. In case of an “advanced” issuance, i.e., where the User has to prove ownership of existing credentials or pseudonyms to carry over attributes or a user secret, the returned IssuanceMessage is simply a wrapper around the issuance policy ip with a fresh Context attribute. The returned boolean value indicates whether this is the last flow of the issuance protocol. If the IssuanceMessage is not the final one, the Issuer will subsequently invoke its issuanceProtocolStep method on the next incoming IssuanceMessage from the User. issuanceProtocolStep(m:IssuanceMessage) → (IssuanceMessage, boolean) This method performs one step in an interactive issuance protocol. On input an incoming issuance message m received from the User, it returns the outgoing issuance message that is to be sent back to the User, plus a boolean value indicating whether this is the last message in the protocol. The Context attribute of the outgoing message has the same value as that of the incoming message, allowing the Issuer to link the different messages of this issuance protocol. 13.6.2Token PresentationIn a typical token presentation interaction, the User first requests access to a protected resource, upon which the Verifier sends a presentation policy that describes which attributes from which credentials the User must choose to generate the proof required for access. The ABC Engine then checks whether it has the necessary credentials to satisfy the Verifier's presentation policy, and if so, generates a presentation token containing the appropriate cryptographic evidence. Upon receiving the presentation token, the Verifier checks that the cryptographic evidence is valid for the presented token and checks that this token satisfies the presentation policy. If both tests succeed, it grants access to the resource. The sequence of a token presentation interaction is illustrated in Figure 3. 
Figure 3: Token Presentation. User side: createPresentationToken(p:PresentationPolicyAlternatives) → PresentationToken This method, on input a presentation policy p, returns a presentation token that satisfies the policy p, or throws an exception if no such token could be created. This method will investigate whether the User has the necessary credentials and/or established pseudonyms to create a token that satisfies the policy. If there are multiple ways in which the policy can be satisfied (e.g., by satisfying different alternatives in the policy, or by using different sets of credentials to satisfy one alternative), this method will invoke an identity selection – possibly presented as a user interface (the executable code of which is installed on the User’s machine as part of the ABCE framework) – to let the User choose her preferred way of generating the presentation token. This method will further invoke a user interface to ensure User consent to the information that will be revealed in the created token. If the policy cannot be satisfied, an exception is thrown. Verifier side: verifyTokenAgainstPolicy(p:PresentationPolicyAlternatives, t:PresentationToken, store:boolean) → PresentationTokenDescription This method, on input a presentation policy p and a presentation token t, checks whether the token t satisfies the policy p, and checks the validity of the cryptographic evidence included in token t. If both checks succeed and store is set to true, this method stores the token in a dedicated store and returns a description of the token that includes a unique identifier by means of which the token can later be retrieved from the store. If one of the checks fails, an exception is thrown and the verification errors are reported in the corresponding exception message. Download 1.78 Mb. Share with your friends:
|