<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html lang="en"><head><title>Draft: OpenID Connect
Extended Authentication Profile (EAP) ACR Values 1.0 - draft 00</title>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="description" content="OpenID Connect
Extended Authentication Profile (EAP) ACR Values 1.0 - draft 00">
<meta name="generator" content="xml2rfc v1.37pre1 (http://xml.resource.org/)">
<style type='text/css'><!--
body {
font-family: verdana, charcoal, helvetica, arial, sans-serif;
font-size: small; color: #000; background-color: #FFF;
margin: 2em;
}
h1, h2, h3, h4, h5, h6 {
font-family: helvetica, monaco, "MS Sans Serif", arial, sans-serif;
font-weight: bold; font-style: normal;
}
h1 { color: #900; background-color: transparent; text-align: right; }
h3 { color: #333; background-color: transparent; }
td.RFCbug {
font-size: x-small; text-decoration: none;
width: 30px; height: 30px; padding-top: 2px;
text-align: justify; vertical-align: middle;
background-color: #000;
}
td.RFCbug span.RFC {
font-family: monaco, charcoal, geneva, "MS Sans Serif", helvetica, verdana, sans-serif;
font-weight: bold; color: #666;
}
td.RFCbug span.hotText {
font-family: charcoal, monaco, geneva, "MS Sans Serif", helvetica, verdana, sans-serif;
font-weight: normal; text-align: center; color: #FFF;
}
table.TOCbug { width: 30px; height: 15px; }
td.TOCbug {
text-align: center; width: 30px; height: 15px;
color: #FFF; background-color: #900;
}
td.TOCbug a {
font-family: monaco, charcoal, geneva, "MS Sans Serif", helvetica, sans-serif;
font-weight: bold; font-size: x-small; text-decoration: none;
color: #FFF; background-color: transparent;
}
td.header {
font-family: arial, helvetica, sans-serif; font-size: x-small;
vertical-align: top; width: 33%;
color: #FFF; background-color: #666;
}
td.author { font-weight: bold; font-size: x-small; margin-left: 4em; }
td.author-text { font-size: x-small; }
/* info code from SantaKlauss at http://www.madaboutstyle.com/tooltip2.html */
a.info {
/* This is the key. */
position: relative;
z-index: 24;
text-decoration: none;
}
a.info:hover {
z-index: 25;
color: #FFF; background-color: #900;
}
a.info span { display: none; }
a.info:hover span.info {
/* The span will display just on :hover state. */
display: block;
position: absolute;
font-size: smaller;
top: 2em; left: -5em; width: 15em;
padding: 2px; border: 1px solid #333;
color: #900; background-color: #EEE;
text-align: left;
}
a { font-weight: bold; }
a:link { color: #900; background-color: transparent; }
a:visited { color: #633; background-color: transparent; }
a:active { color: #633; background-color: transparent; }
p { margin-left: 2em; margin-right: 2em; }
p.copyright { font-size: x-small; }
p.toc { font-size: small; font-weight: bold; margin-left: 3em; }
table.toc { margin: 0 0 0 3em; padding: 0; border: 0; vertical-align: text-top; }
td.toc { font-size: small; font-weight: bold; vertical-align: text-top; }
ol.text { margin-left: 2em; margin-right: 2em; }
ul.text { margin-left: 2em; margin-right: 2em; }
li { margin-left: 3em; }
/* RFC-2629 <spanx>s and <artwork>s. */
em { font-style: italic; }
strong { font-weight: bold; }
dfn { font-weight: bold; font-style: normal; }
cite { font-weight: normal; font-style: normal; }
tt { color: #036; }
tt, pre, pre dfn, pre em, pre cite, pre span {
font-family: "Courier New", Courier, monospace; font-size: small;
}
pre {
text-align: left; padding: 4px;
color: #000; background-color: #CCC;
}
pre dfn { color: #900; }
pre em { color: #66F; background-color: #FFC; font-weight: normal; }
pre .key { color: #33C; font-weight: bold; }
pre .id { color: #900; }
pre .str { color: #000; background-color: #CFF; }
pre .val { color: #066; }
pre .rep { color: #909; }
pre .oth { color: #000; background-color: #FCF; }
pre .err { background-color: #FCC; }
/* RFC-2629 <texttable>s. */
table.all, table.full, table.headers, table.none {
font-size: small; text-align: center; border-width: 2px;
vertical-align: top; border-collapse: collapse;
}
table.all, table.full { border-style: solid; border-color: black; }
table.headers, table.none { border-style: none; }
th {
font-weight: bold; border-color: black;
border-width: 2px 2px 3px 2px;
}
table.all th, table.full th { border-style: solid; }
table.headers th { border-style: none none solid none; }
table.none th { border-style: none; }
table.all td {
border-style: solid; border-color: #333;
border-width: 1px 2px;
}
table.full td, table.headers td, table.none td { border-style: none; }
hr { height: 1px; }
hr.insert {
width: 80%; border-style: none; border-width: 0;
color: #CCC; background-color: #CCC;
}
--></style>
</head>
<body>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<table summary="layout" width="66%" border="0" cellpadding="0" cellspacing="0"><tr><td><table summary="layout" width="100%" border="0" cellpadding="2" cellspacing="1">
<tr><td class="header">Draft</td><td class="header">M. Jones</td></tr>
<tr><td class="header"> </td><td class="header">Microsoft</td></tr>
<tr><td class="header"> </td><td class="header">July 5, 2016</td></tr>
</table></td></tr></table>
<h1><br />OpenID Connect
Extended Authentication Profile (EAP) ACR Values 1.0 - draft 00</h1>
<h3>Abstract</h3>
<p>OpenID Connect 1.0 is a simple identity layer on top of the OAuth 2.0
protocol. It enables Clients to verify the identity of the End-User based
on the authentication performed by an Authorization Server, as well as to
obtain basic profile information about the End-User in an interoperable and
REST-like manner.
</p>
<p>
This specification enables OpenID Connect Relying Parties
to request that specific authentication context classes
be applied to authentications performed and
for OpenID Providers to inform Relying Parties
whether these requests were satisfied.
Specifically, an authentication context class reference value
is defined that requests that
phishing-resistant authentication be performed
and another is defined that requests that
phishing-resistant authentication with a hardware-protected key be performed.
These policies can be satisfied, for instance,
by using W3C scoped credentials
or FIDO authenticators.
</p><a name="toc"></a><br /><hr />
<h3>Table of Contents</h3>
<p class="toc">
<a href="#Introduction">1.</a>
Introduction<br />
<a href="#rnc">1.1.</a>
Requirements Notation and Conventions<br />
<a href="#Terminology">1.2.</a>
Terminology<br />
<a href="#acrValues">2.</a>
Authentication Context Class Reference Values<br />
<a href="#Security">3.</a>
Security Considerations<br />
<a href="#IANA">4.</a>
IANA Considerations<br />
<a href="#acrReg">4.1.</a>
Level of Assurance Profiles Registration<br />
<a href="#ClaimsContents">4.1.1.</a>
Registry Contents<br />
<a href="#rfc.references1">5.</a>
References<br />
<a href="#rfc.references1">5.1.</a>
Normative References<br />
<a href="#rfc.references2">5.2.</a>
Informative References<br />
<a href="#Acknowledgements">Appendix A.</a>
Acknowledgements<br />
<a href="#Notices">Appendix B.</a>
Notices<br />
<a href="#TBD">Appendix C.</a>
Open Issues<br />
<a href="#History">Appendix D.</a>
Document History<br />
<a href="#rfc.authors">§</a>
Author's Address<br />
</p>
<br clear="all" />
<a name="Introduction"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.1"></a><h3>1.
Introduction</h3>
<p>
OpenID Connect 1.0 is a simple identity layer on top of the OAuth 2.0
<a class='info' href='#RFC6749'>[RFC6749]<span> (</span><span class='info'>Hardt, D., Ed., “The OAuth 2.0 Authorization Framework,” October 2012.</span><span>)</span></a>
protocol. It enables Clients to verify the identity of the End-User based
on the authentication performed by an Authorization Server, as well as to
obtain basic profile information about the End-User in an interoperable and
REST-like manner.
</p>
<p>
This specification enables OpenID Connect <a class='info' href='#OpenID.Core'>[OpenID.Core]<span> (</span><span class='info'>Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and C. Mortimore, “OpenID Connect Core 1.0,” November 2014.</span><span>)</span></a> Relying Parties
to request that specific authentication context classes
be applied to authentications performed and
for OpenID Providers to inform Relying Parties
whether these requests were satisfied.
Specifically, an authentication context class reference value
is defined that requests that
phishing-resistant authentication be performed
and another is defined that requests that
phishing-resistant authentication with a hardware-protected key be performed.
These policies can be satisfied, for instance,
by using W3C scoped credentials <a class='info' href='#W3C.WD-webauthn-20160531'>[W3C.WD‑webauthn‑20160531]<span> (</span><span class='info'>Bharadwaj, V., Le Van Gong, H., Balfanz, D., Czeskis, A., Birgisson, A., Hodges, J., B. Jones, M., and R. Lindemann, “Web Authentication: A Web API for accessing scoped credentials,” May 2016.</span><span>)</span></a>
or FIDO authenticators.
</p>
<a name="rnc"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.1.1"></a><h3>1.1.
Requirements Notation and Conventions</h3>
<p>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <a class='info' href='#RFC2119'>RFC 2119<span> (</span><span class='info'>Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.</span><span>)</span></a> [RFC2119].
</p>
<p>
In the .txt version of this specification,
values are quoted to indicate that they are to be taken literally.
When using these values in protocol messages,
the quotes MUST NOT be used as part of the value.
In the HTML version of this specification,
values to be taken literally are indicated by
the use of <tt>this fixed-width font</tt>.
</p>
<a name="Terminology"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.1.2"></a><h3>1.2.
Terminology</h3>
<p>
This specification uses the terms
defined by
<a class='info' href='#OpenID.Core'>OpenID Connect Core 1.0<span> (</span><span class='info'>Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and C. Mortimore, “OpenID Connect Core 1.0,” November 2014.</span><span>)</span></a> [OpenID.Core].
</p>
<a name="acrValues"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.2"></a><h3>2.
Authentication Context Class Reference Values</h3>
<p>
The <tt>acr</tt> (Authentication Context Class Reference) claim
and associated <tt>acr_values</tt> request parameter
are defined by the OpenID Connect Core 1.0 specification
<a class='info' href='#OpenID.Core'>[OpenID.Core]<span> (</span><span class='info'>Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and C. Mortimore, “OpenID Connect Core 1.0,” November 2014.</span><span>)</span></a>.
The following Authentication Context Class Reference values
are defined by this specification:
</p>
<blockquote class="text"><dl>
<dt>phr</dt>
<dd>
Phishing-Resistant.
An authentication mechanism where a party potentially under
the control of the Relying Party cannot gain sufficient
information to be able to successfully authenticate to the End
User's OpenID Provider as if that party were the End User. (Note
that the potentially malicious Relying Party controls where the
User-Agent is redirected to and thus may not send it to the End
User's actual OpenID Provider).
NOTE: These semantics are the same as those specified in <a class='info' href='#OpenID.PAPE'>[OpenID.PAPE]<span> (</span><span class='info'>Recordon, D., Jones, M., Bufu, J., Ed., Daugherty, J., Ed., and N. Sakimura, “OpenID Provider Authentication Policy Extension 1.0,” December 2008.</span><span>)</span></a>.
</dd>
<dt>phrh</dt>
<dd>
Phishing-Resistant Hardware-Protected.
An authentication mechanism meeting the requirements for
phishing-resistant authentication above in which additionally
information needed to be able to successfully authenticate to the End
User's OpenID Provider as if that party were the End User
is held in a hardware-protected device or component.
</dd>
</dl></blockquote><p>
</p>
<a name="Security"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.3"></a><h3>3.
Security Considerations</h3>
<p>
Per commonly accepted security practices, it should be noted that
the overall strength of any authentication is only as strong as its
weakest step. It is thus recommended that provisioning of
phishing-resistant and other credentials stronger than shared secrets
should be accomplished using methods that are at least as strong as the
credential being provisioned. By counter-example, allowing people to
retrieve a phishing-resistant credential using only a phishable shared
secret negates much of the value provided by the phishing-resistant
credential itself.
Similarly, sometimes using a phishing-resistant method when a
phishable method continues to also sometimes be employed may still
enable phishing attacks to compromise the authentication.
</p>
<a name="IANA"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.4"></a><h3>4.
IANA Considerations</h3>
<a name="acrReg"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.4.1"></a><h3>4.1.
Level of Assurance Profiles Registration</h3>
<p>
This specification registers the following values
in the IANA "Level of Assurance Profiles" registry
<a class='info' href='#IANA.LoA'>[IANA.LoA]<span> (</span><span class='info'>IANA, “Level of Assurance Profiles,” .</span><span>)</span></a>
established by <a class='info' href='#RFC6711'>[RFC6711]<span> (</span><span class='info'>Johansson, L., “An IANA Registry for Level of Assurance (LoA) Profiles,” August 2012.</span><span>)</span></a>:
</p>
<a name="ClaimsContents"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.4.1.1"></a><h3>4.1.1.
Registry Contents</h3>
<p>
</p>
<ul class="text">
<li>
URI: http://schemas.openid.net/pape/policies/2007/06/phishing-resistant
</li>
<li>
Name: phr
</li>
<li>
Informational URI: [[ this specification ]]
</li>
<li>
Reference: mbj@microsoft.com
</li>
<li>
Context Class: TBD
</li>
</ul><p>
</p>
<p>
</p>
<ul class="text">
<li>
URI: http://schemas.openid.net/acr/2016/07/phishing-resistant-hardware
</li>
<li>
Name: phrh
</li>
<li>
Informational URI: [[ this specification ]]
</li>
<li>
Reference: mbj@microsoft.com
</li>
<li>
Context Class: TBD
</li>
</ul><p>
</p>
<a name="rfc.references"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.5"></a><h3>5.
References</h3>
<a name="rfc.references1"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<h3>5.1. Normative References</h3>
<table width="99%" border="0">
<tr><td class="author-text" valign="top"><a name="IANA.LoA">[IANA.LoA]</a></td>
<td class="author-text">IANA, “<a href="http://www.iana.org/assignments/loa-profiles">Level of Assurance Profiles</a>.”</td></tr>
<tr><td class="author-text" valign="top"><a name="OpenID.Core">[OpenID.Core]</a></td>
<td class="author-text">Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and C. Mortimore, “<a href="http://openid.net/specs/openid-connect-core-1_0.html">OpenID Connect Core 1.0</a>,” November 2014.</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC2119">[RFC2119]</a></td>
<td class="author-text">Bradner, S., “<a href="http://www.rfc-editor.org/info/rfc2119">Key words for use in RFCs to Indicate Requirement Levels</a>,” BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997.</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC6711">[RFC6711]</a></td>
<td class="author-text">Johansson, L., “<a href="http://www.rfc-editor.org/info/rfc6711">An IANA Registry for Level of Assurance (LoA) Profiles</a>,” RFC 6711, DOI 10.17487/RFC6711, August 2012.</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC6749">[RFC6749]</a></td>
<td class="author-text">Hardt, D., Ed., “<a href="http://www.rfc-editor.org/info/rfc6749">The OAuth 2.0 Authorization Framework</a>,” RFC 6749, DOI 10.17487/RFC6749, October 2012.</td></tr>
</table>
<a name="rfc.references2"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<h3>5.2. Informative References</h3>
<table width="99%" border="0">
<tr><td class="author-text" valign="top"><a name="OpenID.PAPE">[OpenID.PAPE]</a></td>
<td class="author-text"><a href="mailto:david@sixapart.com">Recordon, D.</a>, <a href="mailto:mbj@microsoft.com">Jones, M.</a>, <a href="mailto:johnny.bufu@gmail.com">Bufu, J., Ed.</a>, <a href="mailto:cygnus@janrain.com">Daugherty, J., Ed.</a>, and <a href="mailto:n-sakimura@nri.co.jp">N. Sakimura</a>, “<a href="http://openid.net/specs/openid-provider-authentication-policy-extension-1_0.html">OpenID Provider
Authentication Policy Extension 1.0</a>,” December 2008.</td></tr>
<tr><td class="author-text" valign="top"><a name="W3C.WD-webauthn-20160531">[W3C.WD-webauthn-20160531]</a></td>
<td class="author-text">Bharadwaj, V., Le Van Gong, H., Balfanz, D., Czeskis, A., Birgisson, A., Hodges, J., B. Jones, M., and R. Lindemann, “<a href="http://www.w3.org/TR/2016/WD-webauthn-20160531/">Web Authentication: A Web API for accessing scoped credentials</a>,” World Wide Web Consortium First Public Working Draft WD-webauthn-20160531, May 2016 (<a href="http://www.w3.org/TR/2013/WD-webauthn-20160531/">HTML</a>).</td></tr>
</table>
<a name="Acknowledgements"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.A"></a><h3>Appendix A.
Acknowledgements</h3>
<p>
The phishing-resistant authentication definition is a result of earlier work done
by the OpenID Provider Authentication Policy Extension working group.
</p>
<a name="Notices"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.B"></a><h3>Appendix B.
Notices</h3>
<p>Copyright (c) 2016 The OpenID Foundation.
</p>
<p>The OpenID Foundation (OIDF) grants to any Contributor, developer,
implementer, or other interested party a non-exclusive, royalty free,
worldwide copyright license to reproduce, prepare derivative works from,
distribute, perform and display, this Implementers Draft or Final
Specification solely for the purposes of (i) developing specifications,
and (ii) implementing Implementers Drafts and Final Specifications based
on such documents, provided that attribution be made to the OIDF as the
source of the material, but that such attribution does not indicate an
endorsement by the OIDF.
</p>
<p>The technology described in this specification was made available
from contributions from various sources, including members of the OpenID
Foundation and others. Although the OpenID Foundation has taken steps to
help ensure that the technology is available for distribution, it takes
no position regarding the validity or scope of any intellectual property
or other rights that might be claimed to pertain to the implementation
or use of the technology described in this specification or the extent
to which any license under such rights might or might not be available;
neither does it represent that it has made any independent effort to
identify any such rights. The OpenID Foundation and the contributors to
this specification make no (and hereby expressly disclaim any)
warranties (express, implied, or otherwise), including implied
warranties of merchantability, non-infringement, fitness for a
particular purpose, or title, related to this specification, and the
entire risk as to implementing this specification is assumed by the
implementer. The OpenID Intellectual Property Rights policy requires
contributors to offer a patent promise not to assert certain patent
claims against other contributors and against implementers. The OpenID
Foundation invites any interested party to bring to its attention any
copyrights, patents, patent applications, or other proprietary rights
that may cover technology that may be required to practice this
specification.
</p>
<a name="TBD"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.C"></a><h3>Appendix C.
Open Issues</h3>
<p>
In the IANA registration for the <tt>phr</tt> (phishing-resistant)
acr value, should we reuse the URI http://schemas.openid.net/pape/policies/2007/06/phishing-resistant
already defined by <a class='info' href='#OpenID.PAPE'>[OpenID.PAPE]<span> (</span><span class='info'>Recordon, D., Jones, M., Bufu, J., Ed., Daugherty, J., Ed., and N. Sakimura, “OpenID Provider Authentication Policy Extension 1.0,” December 2008.</span><span>)</span></a> with this meaning,
or define a new one that's parallel to http://schemas.openid.net/acr/2016/07/phishing-resistant-hardware?
(This may not matter a lot since the short names
<tt>phr</tt> and <tt>phrh</tt>
are what would be used in practice in OpenID Connect anyway.)
</p>
<a name="History"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.D"></a><h3>Appendix D.
Document History</h3>
<p>[[ To be removed from the final specification ]]
</p>
<p>
-00
</p>
<ul class="text">
<li>
Created initial version.
</li>
</ul><p>
</p>
<a name="rfc.authors"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<h3>Author's Address</h3>
<table width="99%" border="0" cellpadding="0" cellspacing="0">
<tr><td class="author-text"> </td>
<td class="author-text">Michael B. Jones</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">Microsoft</td></tr>
<tr><td class="author" align="right">Email: </td>
<td class="author-text"><a href="mailto:mbj@microsoft.com">mbj@microsoft.com</a></td></tr>
<tr><td class="author" align="right">URI: </td>
<td class="author-text"><a href="http://self-issued.info/">http://self-issued.info/</a></td></tr>
</table>
</body></html>