dacs_infocard - Information Card administration
This program is part of the DACS
web service is used:
•to perform a variety of administrative
•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, 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) to
create a managed InfoCard.
•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)) and Relying Party must be adequately
synchronized; see INFOCARD_TOKEN_DRIFT_SECS.
•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)), 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),
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 limits):
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.
A unique URI 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
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 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).
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.
This can be thought of as an attribute value.
Technically, this is defined as an xs:string, which is a sequence of
XML characters. Claim values are limited to 64
In addition to the standard CGI arguments
understands the following CGI arguments:
The following operations are supported:
Delete the account associated with USERNAME
. This effectively revokes the
InfoCard; a self-issued InfoCard may be re-registered, but a managed InfoCard
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 the account associated with USERNAME
authentication on this account will fail; this revokes the InfoCard, but in a
reversible way. The request is successful if the account is already
Enable the existing account associated with USERNAME
authentication on this account will be possible. The request is successful if
the account is already enabled.
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 identity.
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., http://schemas.xmlsoap.org/ws/2005/05/identity/claims/webpage). 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
Only the full URI syntax can be used to identify claims in an HTML OBJECT's
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) and dacs_passwd.dtd).
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
, and ENABLE
operations, the request
must be submitted by the account's owner or the DACS
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="privacyUrl" value="https://example.com/infocards/privacy_statement.txt">
<param Name="privacyVersion" value="3">
<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 instead.
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 re-registered.
This functionality should be integrated with dacs_admin(8)
InfoCards With DACS
Distributed Systems Software ( www.dss.ca
Copyright2003-2012 Distributed Systems Software. See the LICENSE
that accompanies the distribution for licensing information.
- claim types
- XML characters
- standard CGI arguments
- Using InfoCards With DACS