DACS_INFOCARD(8)            DACS Web Services Manual            DACS_INFOCARD(8)

       dacs_infocard - Information Card administration

       dacs_infocard [dacsoptions[1]]

       This program is part of the DACS suite.

       The dacs_infocard web service is used:

       •   to perform a variety of administrative InfoCard functions;

       •   as a Relying Party to register a self-issued InfoCard, creating an
           account that can be used for authentication. InfoCard-based
           authentication is performed by local_infocard_authenticate[2], a DACS
           authentication module. These accounts are used only by
           local_infocard_authenticate and are completely separate from any
           other accounts.

       •   to act on behalf of a Relying Party to validate and extract claim
           values from a secure token created from either a self-issued or
           managed InfoCard.

           •   Many Identity Selectors can create a self-issued InfoCard, but
               you must use dacs_managed_infocard(8)[3] to create a managed

           •   If a Relying Party checks that the security token that it
               receives satisfies the validity window condition expressed by the
               token, as it typically will, then the system clocks at the IP/STS
               (e.g., dacs_sts(8)[4]) and Relying Party must be adequately
               synchronized; see INFOCARD_TOKEN_DRIFT_SECS[5].

           •   Owing to the InfoCard system architecture, a Relying Party need
               not have network connectivity to a user's IP/STS (e.g.,
               dacs_sts(8)[4]), although the user's browser must. This means,
               for example, that if a user (or his organization) operates his
               own IP/STS, it can be located on the same side of a firewall as
               the user's browser, which may improve the level of security of
               the IP/STS and any sensitive information it may store and access.

           •   Much of the functionality of this program is also available as a
               DACS utility, dacsinfocard(1)[6], which operates on the same
               account files.

       Accounts are accessed through DACS's virtual filestore using item type

           The official nomenclature for claims can be confusing. In an attempt
           at consistency and simplification, the DACS documentation tries to
           adhere to the following definitions (with the stated compile-time

               A pair comprising an attribute name (the Claim type) and an
               attribute value (the Claim value). The attribute value is
               optional. The number of claims is limited to 10 static claims and
               20 dynamic claims.

           Claim type
               A unique URI[7] that consists of a Claim URI prefix followed by a
               Claim name. This can be thought of as an attribute name.  DACS
               does not allow the URI to include a query or fragment component.
               A claim type is never dereferenced, it is merely a label. Only
               characters that are valid in a URI are allowed; therefore any
               invalid characters must be properly encoded. Claim types are case
               sensitive, despite the fact that they are URIs. There is a
               compile-time length limit: 128 characters for the URI prefix and
               32 characters for the claim name.

           Claim URI prefix
               This URI identifies a namespace in which the Claim name lives (it
               may not include a query or fragment component). Two claim
               types[8] with different URI prefixes but the same claim name are
               distinct. The InfoCard specification uses the namespace
               http://schemas.xmlsoap.org/ws/2005/05/identity/claims for
               self-issued claims.  DACS uses the namespace
               http://dacs.dss.ca/claims for its claims. These namespaces should
               be treated as "reserved". User-defined claims should live in
               other namespaces, preferably ones over which the user has some

           Claim URI prefix abbreviation
               To avoid the tedious and error-prone task of having to repeatedly
               enter long Claim URI prefix strings, in designated contexts DACS
               recognizes (but never requires) an abbreviation. Two
               case-sensitive abbreviations are defined: "standard" (equivalent
               to http://schemas.xmlsoap.org/ws/2005/05/identity/claims) and
               "dacs" (equivalent to http://dacs.dss.ca/claims).

           Claim name
               This is a URI path component. When appended to a Claim URI prefix
               (or paired with a Claim URI prefix abbreviation), it forms a
               Claim type. Only characters that are valid in a URI path
               component are allowed. It is limited to 32 characters.

           Claim value
               This can be thought of as an attribute value. Technically, this
               is defined as an xs:string[9], which is a sequence of XML
               characters[10]. Claim values are limited to 64 characters.

   Web Service Arguments
       In addition to the standard CGI arguments[11], dacs_infocard understands
       the following CGI arguments:

           The following operations are supported:

           •   DELETE

               Delete the account associated with USERNAME. This effectively
               revokes the InfoCard; a self-issued InfoCard may be
               re-registered, but a managed InfoCard becomes unusable.

                   The quickest way to delete all accounts is to delete the
                   contents of the infocards item type; e.g., if infocards
                   points to a file, remove the file or copy /dev/null to it.

           •   DISABLE

               Disable the account associated with USERNAME. InfoCard-based
               authentication on this account will fail; this revokes the
               InfoCard, but in a reversible way. The request is successful if
               the account is already disabled.

           •   ENABLE

               Enable the existing account associated with USERNAME.
               InfoCard-based authentication on this account will be possible.
               The request is successful if the account is already enabled.

           •   LIST

               List all accounts.

           •   REGISTER

               Register or re-register the submitted InfoCard. Exactly one set
               of credentials must accompany the request, and if registration is
               successful, the submitted InfoCard becomes associated with that

           •   TOKEN_ATTRVALS

               If the submitted token is valid, display each claim (attribute)
               value associated with the ATTRLIST argument, which consists of
               zero or more claim names separated by a space. If ATTRLIST is
               absent or the empty string, all claims in the token are displayed
               (note that this is not necessarily all of the claims associated
               with the InfoCard). If any requested claim is not found, the
               request is ignored (i.e., it is not an error). The
               privatepersonalidentifier claim is displayed in the friendly
               identifier syntax rather than as a base-64 encoded string. The
               InfoCard (self-issued or managed) does not need to be registered
               at the jurisdiction.

               Three syntaxes are recognized for a claim name. Some claims are
               "predefined" in that they are available in any valid token:
               issuer, confirm_method, ppid (or privatepersonalidentifier),
               exponent (self-issued only), and modulus (self-issued only). The
               second syntax is the full claim URI (e.g.,
               The third syntax uses the DACS shorthand: the word "standard" or
               "dacs", a colon, and the claim name (e.g., standard:webpage). The
               token is searched for each claim in the ATTRLIST, other than the
               predefined ones.

                   Only the full URI syntax can be used to identify claims in an
                   HTML OBJECT's requiredClaims and optionalClaims param tag.

           •   TOKEN_VALIDATE

               Parse the submitted token and test whether it is valid.

           This is the submitted InfoCard. It is required for the
           TOKEN_VALIDATE, TOKEN_ATTRVALS, and REGISTER operations. The
           AUXILIARY parameter name may only be used for this purpose if the
           xmlToken parameter name is not also used.

           By default, output is emitted in HTML. Several varieties of XML
           output can be selected, however, using the FORMAT argument (please
           refer to dacs(1)[12] and dacs_passwd.dtd[13]). A FORMAT of plain may
           be useful for programs that need to extract claim values; claims are
           listed one per line with the claim type, followed by an "=", followed
           by the claim value.

           For some operations, the name of the account to act on.

       For the DELETE, DISABLE, and ENABLE operations, the request must be
       submitted by the account's owner or the DACS administrator.

       Here is an example of a form that might be used to register a self-issued

           <form name="reg_form" id="reg_form" method="post" action="/cgi-bin/dacs/dacs_infocard">
            <img src="/infocards/ic_image.jpg" onClick="reg_form.submit()"/>
           <object type="application/x-informationCard" name="xmlToken">
            <param name="tokenType" value="urn:oasis:names:tc:SAML:1.0:assertion">
            <param name="issuer" value="http://schemas.xmlsoap.org/ws/2005/05/identity/issuer/self">
            <param name="requiredClaims"
            <param name="privacyUrl" value="https://example.com/infocards/privacy_statement.txt">
            <param Name="privacyVersion" value="3">
           <td align="center">
            <input type="submit" name="infocard_register" value="Register" id="infocard_register" />
           <input type="hidden" name="OPERATION" value="REGISTER">


       The program exits 0 if everything was fine, 1 if an error occurred.

       The compile-time limits are fairly arbitrary and only exist to thwart
       abuse. It should probably be possible to specify them at run-time

       XML output is not available yet.

       Registration of a self-issued InfoCard uses the card's PPID (Private
       Personal Identifier), which differs for a given InfoCard for different
       Relying Parties. The specification does not precisely define how two
       Relying Party endpoints are compared for equality, but if an identity
       selector decides that a jurisdiction's endpoint has changed (e.g., its
       domain name has been reconfigured), all self-issued InfoCards previously
       registered at the jurisdiction will become unusable until they are

       This functionality should be integrated with dacs_admin(8)[15].

       dacsinfocard(1)[6], dacs.conf(5)[16], dacs_authenticate(8)[17],
       dacs_managed_infocard(8)[3], Using InfoCards With DACS[18]

       Distributed Systems Software (www.dss.ca[19])

       Copyright © 2003-2012 Distributed Systems Software. See the LICENSE[20]
       file that accompanies the distribution for licensing information.

        1. dacsoptions

        2. local_infocard_authenticate

        3. dacs_managed_infocard(8)

        4. dacs_sts(8)


        6. dacsinfocard(1)

        7. URI

        8. claim types

        9. xs:string

       10. XML characters

       11. standard CGI arguments

       12. dacs(1)

       13. dacs_passwd.dtd

       14. dacs_infocard.css

       15. dacs_admin(8)

       16. dacs.conf(5)

       17. dacs_authenticate(8)

       18. Using InfoCards With DACS

       19. www.dss.ca

       20. LICENSE

DACS 1.4.40                        02/19/2019                   DACS_INFOCARD(8)