Provided by: dacs_1.4.28b-3ubuntu1_amd64 
NAME
dacs_infocard - Information Card administration
SYNOPSIS
dacs_infocard [dacsoptions[1]]
DESCRIPTION
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.
Notes
• Many Identity Selectors can create a self-issued InfoCard, but you must use
dacs_managed_infocard(8)[3] 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)[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 infocards.
Note
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):
Claim
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 authority.
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.
OPTIONS
Web Service Arguments
In addition to the standard CGI arguments[11], dacs_infocard understands the following CGI
arguments:
OPERATION
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.
Note
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 identity.
• 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.,
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 predefined ones.
Note
Only the full URI syntax can be used to identify claims in an HTML OBJECT's
requiredClaims and optionalClaimsparam tag.
• TOKEN_VALIDATE
Parse the submitted token and test whether it is valid.
xmlToken
AUXILIARY
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.
FORMAT
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.
USERNAME
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 InfoCard:
<form name="reg_form" id="reg_form" method="post" action="/cgi-bin/dacs/dacs_infocard">
<table>
<tr>
<td>
<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"
value="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/privatepersonalidentifier">
<param name="privacyUrl" value="https://example.com/infocards/privacy_statement.txt">
<param Name="privacyVersion" value="3">
</object>
</td>
</tr>
<tr>
<td align="center">
<input type="submit" name="infocard_register" value="Register" id="infocard_register" />
</td>
<td>
</td>
</table>
<input type="hidden" name="OPERATION" value="REGISTER">
</form>
FILES
dacs_infocard.css[14]
DIAGNOSTICS
The program exits 0 if everything was fine, 1 if an error occurred.
BUGS
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)[15].
SEE ALSO
dacsinfocard(1)[6], dacs.conf(5)[16], dacs_authenticate(8)[17],
dacs_managed_infocard(8)[3], Using InfoCards With DACS[18]
AUTHOR
Distributed Systems Software (www.dss.ca[19])
COPYING
Copyright2003-2012 Distributed Systems Software. See the LICENSE[20] file that accompanies
the distribution for licensing information.
NOTES
1. dacsoptions
http://dacs.dss.ca/man/dacs.1.html#dacsoptions
2. local_infocard_authenticate
http://dacs.dss.ca/man/dacs_authenticate.8.html#local_infocard_authenticate
3. dacs_managed_infocard(8)
http://dacs.dss.ca/man/dacs_managed_infocard.8.html
4. dacs_sts(8)
http://dacs.dss.ca/man/dacs_sts.8.html
5. INFOCARD_TOKEN_DRIFT_SECS
http://dacs.dss.ca/man/dacs.conf.5.html#INFOCARD_TOKEN_DRIFT_SECS
6. dacsinfocard(1)
http://dacs.dss.ca/man/dacsinfocard.1.html
7. URI
http://www.rfc-editor.org/rfc/rfc3986.txt
8. claim types
http://dacs.dss.ca/man/#claim_types
9. xs:string
http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#string
10. XML characters
http://www.w3.org/TR/2000/WD-xml-2e-20000814#NT-Char
11. standard CGI arguments
http://dacs.dss.ca/man/dacs.services.8.html#standard_cgi_args
12. dacs(1)
http://dacs.dss.ca/man/dacs.1.html
13. dacs_passwd.dtd
http://dacs.dss.ca/man/../dtd-xsd/dacs_passwd.dtd
14. dacs_infocard.css
http://dacs.dss.ca/man//css/dacs_infocard.css
15. dacs_admin(8)
http://dacs.dss.ca/man/dacs_admin.8.html
16. dacs.conf(5)
http://dacs.dss.ca/man/dacs.conf.5.html
17. dacs_authenticate(8)
http://dacs.dss.ca/man/dacs_authenticate.8.html
18. Using InfoCards With DACS
http://dacs.dss.ca/man/using-infocards-with-dacs.html
19. www.dss.ca
http://www.dss.ca
20. LICENSE
http://dacs.dss.ca/man/../misc/LICENSE