This page has moved to

GENI ABAC Credentials

GENI  ABAC credentials are used to store or communicate ABAC statements directly. This format describes a format for passing RT0 credentials, which can express the statements described here. In GENI, credentials are typically passed around in a struct that identifies the type and version of the credential. For GENI API purposes, this page describes credentials of the type geni_abac and version 1.

ABAC credentials are, like GENI SFA privilege credentials, XML documents signed using  XML dsig. The contents of an ABAC credential are contained in a signed-credential element. The ABAC data is in a credential element and signature information in the signatures element. The signatures element holds XML digital signature information, signing the credential element.

This page describes both the initial, deprecated version 1.0 abac credential and the new version 1.1 credential that more closely follows the GENI SFA credential format. (Note that both are known within GENI as type geni_abac version 1.) Version 1.0 (never deployed) made changes to the credential element itself, while version 1.1 uses the type field to add an abac element parallel to the privilege element. In addition, version 1.1 encodes the ABAC statement inside XML clauses so other XML tools can understand it should they need to. In addition, the principal names - SHA-1 public key hashes - are annotated with human-readable names that can be used by  libabac or third party applications.

Version 1.1 Credentials

Intuitively, Version 1.1 credentials modify the GENI SFA credentials by making a type of "abac" valid in the type element, and adding an abac element parallel to the privilege, ticket, and capabilities elements. The abac field includes the version of the ABAC encoding (1.1) and the ABAC statement encoded in XML.

  • The version element is 2 non-negative integers separated by a period. No spaces. A major and minor version number. This section describes version 1.1

Some fields of the GENI SFA credential make little sense for the ABAC credential. The libabac implementation produces empty elements for these fields and ignores their presence when parsed:

  • serial
  • owner_gid
  • owner_urn (not generated)
  • target_gid
  • target_urn (not generated)
  • uuid

The expires element specifies the expiration of the credential. It is in the same format as the GENI privilege credential (ISO 8601 with UTC assumed if no timezone is specified, RFC 3339 format preferred).

When the type element is "abac", an abac element must be present. The abac field contains a single rt0 element with one head element and one or more tail elements. Each head or tail element contains

  • The head element must include a keyid containing the SHA1 hash of the public key contained in the x509 certificate that signed this credential (and which is attached in the signature).
  • An ABACprincipal element. This contains
    • A keyid element that contains the SHA-1 hash of the principal's public key (from the principal's X509 certificate)
    • An optional mnemonic element that contains a human-readable name of the principal, used in presenting the contents to people (E.G. something from the DN or SubjectAltName of the principal's certificate; In GENI, typically the URN.
  • An optional role element. This contains a string, the last clause in the RT0 term.
  • An optional linking_role element. This contains a string, the middle clause in an RT0 term. A linking_role element must not appear without a role element.

The RT0 term "e80dc149dfdfaf18e2ecd230a2b214d731d8910f.partner.experiment_create" looks like this in the XML representation:


If the keyid "e80dc149dfdfaf18e2ecd230a2b214d731d8910f" refers to a principal named "Acme" then the element might be annotated with a mnemonic element:


A full Version 1.1 credential encoding the RT0 statement Acme.experiment_create <- Acme.partner.experiment_create (with signature contents trimmed) looks like:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
 <credential xml:id="ref0">

Multiple tail elements are treated an intersection element - all the tails must hold to assign the head.

The xsd additions to  the GENIAPI credential XSD are attached Download to this page. They encode the rt0 element inside the abac element. Minor additions need to be made to add the abac element as a choice.

This credential is only valid if:

  • It validates against the schema (attached)
  • The XML signature is valid per the XML-DSig standard
  • The signing certificate is valid and trusted (see the GENI certificates page).
  • The expiration date has not passed
  • The keyid of the head matches the credential signer (the SHA1 hash of the public key in the signing certificate)

Further details on verification can be found on the GENI SFA credential page.

Note that these credentials may not be delegated (in contrast to GENI SFA credentials).

Version 1.0 Credentials (deprecated)

The credential element contains:

  • A type element whose content is "abac" this differentiates it from a GENI privilege credential
  • A version element whose content is 2 non-negative integers separated by a period. No spaces. A major and minor version number. This page describes version 1.0
  • An expires element whose content defines the last time the credential is valid. It is in the same format as the GENI privilege credential.
  • An rt0 element that includes an encoding of the RT0 rule. All take the form Principal.Attr <- RHS according to the following rules
    • Principals are encoded by their Subject Key Identifier - a SHA1 hash of their public key data. These are shown in italics below.
    • Attributes are space-free strings containing alpha-numeric data and underscores.
    • An assignment of an attribute to a principal is of the form issuer.attr <- principal
    • An assignment of an attribute to a set of principals that have an attribute is of the form issuer.role1 <- principal.role2
    • An assignment of an attribute to a set of principals assigned a given attribute by a principal with a given linking attribute has the form issuer.role1 <- principal.linking_attribute.role2. See here for examples of this type of role.
    • The right side of the assignment (RHS) may be a conjunction of the various RHS types above, e.g., issuer.role0 <- principal1.role1 & principal2.role2

An example abac credential (formatted for display which may invalidate the signature) follows. Note that the <- in the <rt0> element has been escaped as &lt;-.

 <credential xml:id="ref0">
  <Signature xmlns="">
    <CanonicalizationMethod Algorithm=""/>
    <SignatureMethod Algorithm=""/>
    <Reference URI="#ref0">
      <Transform Algorithm=""/>
     <DigestMethod Algorithm=""/>