<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">A number of comments. <div class=""><br class=""></div><div class="">There are issues with the way that offline access is defined today. I think a number of these also translate to an online access scope, plus a few additional issues.</div><div class=""><br class=""></div><div class="">First, offline_access is unfortunately defined tied to refresh tokens, when no _actual_ protocol tie is present (nor is the use of refresh tokens in offline access patterns a MUST).</div><div class=""><br class=""></div><div class="">I can have refresh tokens in an authorization tied to the OP concept of a user session. Likewise, I can issue a non-time-limited access token for a confidential client to use, without a refresh token and with expiry only being via some external process. The definition of offline_access has caused unfortunate confusion by implementors, who believe refresh tokens are somehow incompatible with tying authentication to a user session, and that refresh tokens are required for independent access.</div><div class=""><br class=""></div><div class="">However, I don’t believe this requires a new scope name. Rather, this could be solved with clarifying how offline_access may be applied outside the context of OpenID Connect.</div><div class=""><br class=""></div><div class="">Secondly (and IMHO), use of offline_access itself is an anti-pattern for some deployments. A single client’s behavior within the system will almost never dynamic enough to need offline behavior for a user in one case, and session-bound behavior in another. Generically expecting clients to indicate whether they need offline behavior is a sign that clients in the environment are not properly classified or audited for their actual needs. The only AS/OP environments where this really is acceptable is when you expect users to be the sole line of defense against inappropriate requests by clients for permissions - but even large social providers like Facebook and GitHub have started to decide this is unacceptable.</div><div class=""><br class=""></div><div class="">Finally, (and also IMHO) while I understand the modeling of online_access to be explicit that underspecified clients should have any refresh tokens bound to the session, I don’t believe a scope is appropriate way to model a client opting into _limitations_ on the authorization. Other scopes when requested increase the capabilities of the token or the information the client has access to - access to authentication information and user claims with most of the OIDC-defined scopes, access to additional API capabilities with typical OAuth scopes. In this case, clients would be opting into having to send the user through an authorization UX more often - which is not something I see a client developer normally seeking out how to do. </div><div class=""><br class=""></div><div class="">As part of the overall authentication and authorization policy this is all the responsibility of the OP to dictate. It is not appropriate for the client to opt into behavior based on its own self-assertion around security and design.</div><div class=""><br class=""></div><div class="">I further assert that in the rare cases where it is appropriate for a client to indicate off-line or on-line patterns for access, these are the only two apparent policy options which could be broadly standardized. In that case, the absence of an offline_access scope is the same as some online_access scope.</div><div class=""><br class=""></div><div class="">-DW</div><div class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Dec 21, 2019, at 12:24 PM, Karl McGuinness via Openid-specs-ab <<a href="mailto:openid-specs-ab@lists.openid.net" class="">openid-specs-ab@lists.openid.net</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">

<meta http-equiv="Content-Type" content="text/html; charset=us-ascii" class="">

<div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">
<div style="font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; background-color: rgb(255, 255, 255);" class="">
<div style="margin-bottom: 15px; caret-color: rgb(0, 0, 0); font-family: Helvetica, arial, sans-serif; font-size: 14px; font-weight: normal; margin-top: 0px; background-color: rgb(255, 255, 255);" class="">
<a href="https://gist.github.com/mcguinness/85116690d556f8ddf280143469063a6c" id="LPlnk774965" class="">https://gist.github.com/mcguinness/85116690d556f8ddf280143469063a6c</a><br class="">
</div>
<div id="LPBorder_GTaHR0cHM6Ly9naXN0LmdpdGh1Yi5jb20vbWNndWlubmVzcy84NTExNjY5MGQ1NTZmOGRkZjI4MDE0MzQ2OTA2M2E2Yw.." class="LPBorder699699" contenteditable="false" style="width: 800px; margin-top: 16px; margin-bottom: 16px; position: relative; max-width: 800px; min-width: 424px;">
<table id="LPContainer699699" role="presentation" style="padding: 12px 36px 12px 12px; width: 750px; border: 1px solid rgb(200, 200, 200); border-top-left-radius: 2px; border-top-right-radius: 2px; border-bottom-right-radius: 2px; border-bottom-left-radius: 2px;" class="">
<tbody class="">
<tr valign="top" style="border-spacing: 0px;" class="">
<td class="">
<div id="LPImageContainer699699" style="position: relative; margin-right: 12px; height: 120px; overflow: hidden; width: 240px;" class="">
<a target="_blank" id="LPImageAnchor699699" href="https://gist.github.com/mcguinness/85116690d556f8ddf280143469063a6c" class=""><img id="LPThumbnailImageId699699" alt="" height="120" width="240" src="https://github.githubassets.com/images/modules/gists/gist-og-image.png" style="display: block;" class=""></a></div>
</td>
<td style="width: 488px;" class="">
<div id="LPTitle699699" style="font-size: 21px; font-weight: 300; margin-right: 8px; font-family: wf_segoe-ui_light, "Segoe UI Light", "Segoe WP Light", "Segoe UI", "Segoe WP", Tahoma, Arial, sans-serif; margin-bottom: 12px;" class="">
<a target="_blank" id="LPUrlAnchor699699" href="https://gist.github.com/mcguinness/85116690d556f8ddf280143469063a6c" style="text-decoration: none; color: var(--themePrimary);" class="">Online Access Refresh Tokens</a></div>
<div id="LPDescription699699" style="font-size: 14px; max-height: 100px; font-family: wf_segoe-ui_normal, "Segoe UI", "Segoe WP", Tahoma, Arial, sans-serif; margin-bottom: 12px; margin-right: 8px; overflow: hidden; color: rgb(102, 102, 102);" class="">
Online Access Refresh Tokens. GitHub Gist: instantly share code, notes, and snippets.</div>
<div id="LPMetadata699699" style="font-size: 14px; font-weight: 400; font-family: wf_segoe-ui_normal, "Segoe UI", "Segoe WP", Tahoma, Arial, sans-serif; color: rgb(166, 166, 166);" class="">
<a href="http://gist.github.com/" class="">gist.github.com</a></div>
</td>
</tr>
</tbody>
</table>
</div>
Hello OpenID Connect WG,</div>
<div style="font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; background-color: rgb(255, 255, 255);" class="">
<br class=""><p style="margin-bottom: 15px; caret-color: rgb(0, 0, 0); font-family: Helvetica, arial, sans-serif; font-size: 14px; font-weight: normal; background-color: rgb(255, 255, 255); margin-top: 0px !important;" class="">
I hosted a session at IIW last fall discussing the need to introduce support for<span class=""> </span><code style="margin: 0px 2px; padding: 0px 5px; border: 1px solid rgb(234, 234, 234); border-top-left-radius: 3px; border-top-right-radius: 3px; border-bottom-right-radius: 3px; border-bottom-left-radius: 3px; background-color: rgb(248, 248, 248);" class="">online_access</code><span class=""> </span>refresh
 tokens. I promised to write up the takeaways and send to the OpenID Connect mailing list. I finally found the time before the year closes to complete that promise!</p>
<h1 style="margin: 20px 0px 10px; font-weight: bold; cursor: text; font-size: 28px; font-family: Helvetica, arial, sans-serif; background-color: rgb(255, 255, 255);" class="">
Problem Statement</h1><p style="margin: 15px 0px; caret-color: rgb(0, 0, 0); font-family: Helvetica, arial, sans-serif; font-size: 14px; font-weight: normal; background-color: rgb(255, 255, 255);" class="">
The<span class=""> </span><a href="https://tools.ietf.org/html/rfc6749" style="color: rgb(65, 131, 196);" class="">OAuth 2.0 Authorization Framework</a><span class=""> </span>defines the<span class=""> </span><code style="margin: 0px 2px; padding: 0px 5px; border: 1px solid rgb(234, 234, 234); border-top-left-radius: 3px; border-top-right-radius: 3px; border-bottom-right-radius: 3px; border-bottom-left-radius: 3px; background-color: rgb(248, 248, 248);" class="">authorization_code</code><span class=""> </span>grant
 type and refresh token. It doesn't establish any rules for issuing refresh tokens and explicitly states in<span class=""> </span><a href="https://tools.ietf.org/html/rfc6749#section-1.5" style="color: rgb(65, 131, 196);" class="">Section 1.5</a><span class=""> </span>that
 "Issuing a refresh token is optional at the discretion of the authorization server". One of the explicit goals for Rfc6749 was to enable offline access to protected resources when the end-user is not present. It does not define any request semantics for how
 a client can explicitly request a refresh token or whether that refresh token's lifecycle should be bound to the user's session that granted the refresh token. Authorization Servers are free to define these behaviors on a per-implementation or policy basis.</p><p style="margin: 15px 0px; caret-color: rgb(0, 0, 0); font-family: Helvetica, arial, sans-serif; font-size: 14px; font-weight: normal; background-color: rgb(255, 255, 255);" class="">
OpenID Connect being the identity layer ontop of OAuth 2.0 needed to define some new authorization server behaviors to enable end-user consent for when a client can access their identity info (UserInfo). This resulted in a new scope<span class=""> </span><a href="https://openid.net/specs/openid-connect-core-1_0.html#OfflineAccess" style="color: rgb(65, 131, 196);" class="">offline_access</a><span class=""> </span>being
 defined to allow a client to access their identity info when they are not present.</p>
<div style="caret-color: rgb(0, 0, 0); font-family: Helvetica, arial, sans-serif; font-size: 14px; font-weight: normal; background-color: rgb(255, 255, 255);" class="">
<pre style="margin: 0.5em 0px 1em; border-width: 1px 1px 1px 10px; border-style: solid; border-color: rgb(204, 204, 204) rgb(204, 204, 204) rgb(204, 204, 204) rgb(53, 140, 203); font-size: 13px; line-height: 1.5; border-top-left-radius: 3px; border-top-right-radius: 3px; border-bottom-right-radius: 3px; border-bottom-left-radius: 3px; background-image: linear-gradient(transparent 50%, rgba(69, 142, 209, 0.0392157) 50%); background-size: 3em 3em; background-origin: content-box; font-family: Consolas, Monaco, "Andale Mono", "Ubuntu Mono", monospace; text-align: left; word-spacing: normal; tab-size: 4; box-shadow: rgb(53, 140, 203) -1px 0px 0px 0px, rgb(223, 223, 223) 0px 0px 0px 1px; box-sizing: border-box; background-color: rgb(253, 253, 253);" class=""><code style="margin: 0px; padding: 0px 1em; border: none; border-top-left-radius: 3px; border-top-right-radius: 3px; border-bottom-right-radius: 3px; border-bottom-left-radius: 3px; background-image: none; tab-size: 4; height: 38px; display: block; overflow: auto;" class="">offline_access
OPTIONAL. This scope value requests that an OAuth 2.0 Refresh Token be issued that can be used to obtain an Access Token that grants access to the End-User's UserInfo Endpoint even when the End-User is not present (not logged in).</code></pre>
</div><p style="margin: 15px 0px; caret-color: rgb(0, 0, 0); font-family: Helvetica, arial, sans-serif; font-size: 14px; font-weight: normal; background-color: rgb(255, 255, 255);" class="">
OpenID Connect 1.0 does not define how the<span class=""> </span><code style="margin: 0px 2px; padding: 0px 5px; border: 1px solid rgb(234, 234, 234); border-top-left-radius: 3px; border-top-right-radius: 3px; border-bottom-right-radius: 3px; border-bottom-left-radius: 3px; background-color: rgb(248, 248, 248);" class="">offline_access</code><span class=""> </span>scope
 should constrain access to other protected resources, nor does it define the behavior of the refresh token if this scope is not requested. Authorization Servers are free to define behaviors for other protected resources and/or non-OIDC defined scopes when<span class=""> </span><code style="margin: 0px 2px; padding: 0px 5px; border: 1px solid rgb(234, 234, 234); border-top-left-radius: 3px; border-top-right-radius: 3px; border-bottom-right-radius: 3px; border-bottom-left-radius: 3px; background-color: rgb(248, 248, 248);" class="">offline_access</code><span class=""> </span>is
 requested.</p>
<blockquote style="margin: 15px 0px; border-left-width: 4px; border-left-style: solid; border-left-color: rgb(221, 221, 221); padding: 0px 15px; font-family: Helvetica, arial, sans-serif; font-size: 14px; font-weight: normal; color: rgb(119, 119, 119); background-color: rgb(255, 255, 255);" class=""><div style="margin: 0px;" class="">The use of Refresh Tokens is not exclusive to the offline_access use case. The Authorization Server MAY grant Refresh Tokens in other contexts that are beyond the scope of this specification.</div>
</blockquote><p style="margin: 15px 0px; caret-color: rgb(0, 0, 0); font-family: Helvetica, arial, sans-serif; font-size: 14px; font-weight: normal; background-color: rgb(255, 255, 255);" class="">
There are many large scale OAuth 2.0 deployments the have chosen to only issue refresh tokens for delegated access to their protected non-identity resources only if<span class=""> </span><code style="margin: 0px 2px; padding: 0px 5px; border: 1px solid rgb(234, 234, 234); border-top-left-radius: 3px; border-top-right-radius: 3px; border-bottom-right-radius: 3px; border-bottom-left-radius: 3px; background-color: rgb(248, 248, 248);" class="">offline_access</code><span class=""> </span>scope
 is requested. This approach often simplified Authorization Server complexity and developer documentation by linking the<span class=""> </span><code style="margin: 0px 2px; padding: 0px 5px; border: 1px solid rgb(234, 234, 234); border-top-left-radius: 3px; border-top-right-radius: 3px; border-bottom-right-radius: 3px; border-bottom-left-radius: 3px; background-color: rgb(248, 248, 248);" class="">offline_access</code><span class=""> </span>OIDC
 constrain to<span class=""> </span><em class="">all</em><span class=""> </span>protected resources.</p><p style="margin: 15px 0px; caret-color: rgb(0, 0, 0); font-family: Helvetica, arial, sans-serif; font-size: 14px; font-weight: normal; background-color: rgb(255, 255, 255);" class="">
OpenID Connect 1.0 also does not define any new behaviors for when an issued refresh tokens should be linked to the authentication session that issued the authorization code/refresh token. Logging out of the OP is an implementation-specific behavior with respect
 to any issued refresh tokens that were not requested with<span class=""> </span><code style="margin: 0px 2px; padding: 0px 5px; border: 1px solid rgb(234, 234, 234); border-top-left-radius: 3px; border-top-right-radius: 3px; border-bottom-right-radius: 3px; border-bottom-left-radius: 3px; background-color: rgb(248, 248, 248);" class="">offline_access</code><span class=""> </span>scope.</p><p style="margin: 15px 0px; caret-color: rgb(0, 0, 0); font-family: Helvetica, arial, sans-serif; font-size: 14px; font-weight: normal; background-color: rgb(255, 255, 255);" class="">
This lack of clarity hasn't historically been a significant issue as refresh tokens were restricted from being issued via the<span class=""> </span><code style="margin: 0px 2px; padding: 0px 5px; border: 1px solid rgb(234, 234, 234); border-top-left-radius: 3px; border-top-right-radius: 3px; border-bottom-right-radius: 3px; border-bottom-left-radius: 3px; background-color: rgb(248, 248, 248);" class="">implicit</code>grant
 in<span class=""> </span><a href="https://tools.ietf.org/html/rfc6749#section-4.2" style="color: rgb(65, 131, 196);" class="">Section 4.2</a>. Refresh tokens were often only used for web or native clients where<span class=""> </span><code style="margin: 0px 2px; padding: 0px 5px; border: 1px solid rgb(234, 234, 234); border-top-left-radius: 3px; border-top-right-radius: 3px; border-bottom-right-radius: 3px; border-bottom-left-radius: 3px; background-color: rgb(248, 248, 248);" class="">offline_access</code><span class=""> </span>was
 the desired behavior (raison d'etre of OAuth 2.0)</p><p style="margin: 15px 0px; caret-color: rgb(0, 0, 0); font-family: Helvetica, arial, sans-serif; font-size: 14px; font-weight: normal; background-color: rgb(255, 255, 255);" class="">
As developers shift to more browser-based applications (e.g Single Page Apps) and leverage cloud identity services, the need to resolve this undefined behavior has reached a tipping point. The<span class=""> </span><a href="https://tools.ietf.org/html/draft-ietf-oauth-browser-based-apps-04" style="color: rgb(65, 131, 196);" class="">OAuth
 2.0 for Browser-Based Apps BCP</a><span class=""> </span>and<span class=""> </span><a href="https://tools.ietf.org/html/draft-ietf-oauth-security-topics-13" style="color: rgb(65, 131, 196);" class="">OAuth 2.0 Security Best Current Practice BCP</a><span class=""> </span>deprecate
 the<span class=""> </span><code style="margin: 0px 2px; padding: 0px 5px; border: 1px solid rgb(234, 234, 234); border-top-left-radius: 3px; border-top-right-radius: 3px; border-bottom-right-radius: 3px; border-bottom-left-radius: 3px; background-color: rgb(248, 248, 248);" class="">implicit</code><span class=""> </span>grant
 and require all browser-based applications to use the<span class=""> </span><code style="margin: 0px 2px; padding: 0px 5px; border: 1px solid rgb(234, 234, 234); border-top-left-radius: 3px; border-top-right-radius: 3px; border-bottom-right-radius: 3px; border-bottom-left-radius: 3px; background-color: rgb(248, 248, 248);" class="">authorization_code</code><span class=""> </span>grant
 with PKCE. This change requires defining new behaviors for refresh tokens in the browser where it previously never was used.<span class=""> </span><a href="https://tools.ietf.org/html/draft-ietf-oauth-browser-based-apps-04#section-8" style="color: rgb(65, 131, 196);" class="">Section
 8</a>of the BCP defines security mitigations to prevent refresh tokens from being leaked but does not define what should happen if the user logs out of the authorization server.<span class=""> </span></p><p style="margin: 15px 0px; caret-color: rgb(0, 0, 0); font-family: Helvetica, arial, sans-serif; font-size: 14px; font-weight: normal; background-color: rgb(255, 255, 255);" class="">
When browser-based apps used the<span class=""> </span><code style="margin: 0px 2px; padding: 0px 5px; border: 1px solid rgb(234, 234, 234); border-top-left-radius: 3px; border-top-right-radius: 3px; border-bottom-right-radius: 3px; border-bottom-left-radius: 3px; background-color: rgb(248, 248, 248);" class="">implicit</code><span class=""> </span>grant
 they often used patterns like making authentication requests with<span class=""> </span><code style="margin: 0px 2px; padding: 0px 5px; border: 1px solid rgb(234, 234, 234); border-top-left-radius: 3px; border-top-right-radius: 3px; border-bottom-right-radius: 3px; border-bottom-left-radius: 3px; background-color: rgb(248, 248, 248);" class="">prompt=none</code><span class=""> </span>to
 silently request new access tokens when previously issued access tokens were expired. This pattern relied on the client and the end-user being in the same browser context and having a session with the OP. Logout at OP would prevent these clients from obtaining
 new access tokens. This not only had security benefits but also user experience benefits especially when switching accounts at the OP.</p>
<h1 style="margin: 20px 0px 10px; font-weight: bold; cursor: text; font-size: 28px; font-family: Helvetica, arial, sans-serif; background-color: rgb(255, 255, 255);" class="">
Proposal</h1><p style="margin: 15px 0px; caret-color: rgb(0, 0, 0); font-family: Helvetica, arial, sans-serif; font-size: 14px; font-weight: normal; background-color: rgb(255, 255, 255);" class="">
It is desirable to have an explicit pattern for a client to opt-in to a refresh token that is tightly coupled to the user's session at the Authorization Server. An explicit pattern enables the client to express it's intent on whether it wants to operate in
 a connected or disconnected mode. The Authorization Server can choose to honor this intent or not based on policy.</p><p style="margin: 15px 0px; caret-color: rgb(0, 0, 0); font-family: Helvetica, arial, sans-serif; font-size: 14px; font-weight: normal; background-color: rgb(255, 255, 255);" class="">
The recommendation was to introduce a new<span class=""> </span><code style="margin: 0px 2px; padding: 0px 5px; border: 1px solid rgb(234, 234, 234); border-top-left-radius: 3px; border-top-right-radius: 3px; border-bottom-right-radius: 3px; border-bottom-left-radius: 3px; background-color: rgb(248, 248, 248);" class="">online_access</code><span class=""> </span>scope
 that when requested, binds the issued refresh token to user's session on the Authorization Server. If the user's session is closed or revoked either directly by end-user or indirectly by the Authorization Server such as an inactivity timeout policy the refresh
 token and children access tokens issued with the refresh token MUST be revoked by the Authorization Server.</p><p style="margin: 15px 0px; caret-color: rgb(0, 0, 0); font-family: Helvetica, arial, sans-serif; font-size: 14px; font-weight: normal; background-color: rgb(255, 255, 255);" class="">
Revoking the issued refresh token directly via Token Revocation Endpoint or indirectly via the Authorization Server should only revoke the refresh token and children access tokens and not the user's session.<span class=""> </span></p><p style="margin: 15px 0px; caret-color: rgb(0, 0, 0); font-family: Helvetica, arial, sans-serif; font-size: 14px; font-weight: normal; background-color: rgb(255, 255, 255);" class="">
If the need arises to revoke the user's session at the Authorization Server via the backchannel with a Refresh Token, then a new extension to Logout Specifications should be defined.</p><p style="margin: 15px 0px; caret-color: rgb(0, 0, 0); font-family: Helvetica, arial, sans-serif; font-size: 14px; font-weight: normal; background-color: rgb(255, 255, 255);" class="">
The recommendation was to define the new<span class=""> </span><code style="margin: 0px 2px; padding: 0px 5px; border: 1px solid rgb(234, 234, 234); border-top-left-radius: 3px; border-top-right-radius: 3px; border-bottom-right-radius: 3px; border-bottom-left-radius: 3px; background-color: rgb(248, 248, 248);" class="">online_access</code><span class=""> </span>in
 OIDF as this is consistent with<span class=""> </span><code style="margin: 0px 2px; padding: 0px 5px; border: 1px solid rgb(234, 234, 234); border-top-left-radius: 3px; border-top-right-radius: 3px; border-bottom-right-radius: 3px; border-bottom-left-radius: 3px; background-color: rgb(248, 248, 248);" class="">offline_access</code><span class=""> </span>and
 relates to authentication concerns. Once defined in OIDF, we can reference in OAuth 2.0 for Browser-Based Apps BCP. We should maybe consider introducing a new client application_type (e.g. browser) that requires<span class=""> </span><code style="margin: 0px 2px; padding: 0px 5px; border: 1px solid rgb(234, 234, 234); border-top-left-radius: 3px; border-top-right-radius: 3px; border-bottom-right-radius: 3px; border-bottom-left-radius: 3px; background-color: rgb(248, 248, 248);" class="">online_access</code><span class=""> </span>scope.</p>
<h1 style="margin: 20px 0px 10px; font-weight: bold; cursor: text; font-size: 28px; font-family: Helvetica, arial, sans-serif; background-color: rgb(255, 255, 255);" class="">
Precedence</h1><p style="margin: 15px 0px; caret-color: rgb(0, 0, 0); font-family: Helvetica, arial, sans-serif; font-size: 14px; font-weight: normal; background-color: rgb(255, 255, 255);" class="">
The healthcare domain has defined a similar use of<span class=""> </span><code style="margin: 0px 2px; padding: 0px 5px; border: 1px solid rgb(234, 234, 234); border-top-left-radius: 3px; border-top-right-radius: 3px; border-bottom-right-radius: 3px; border-bottom-left-radius: 3px; background-color: rgb(248, 248, 248);" class="">online_access</code><span class=""> </span>with
 the<span class=""> </span><a href="http://www.hl7.org/fhir/smart-app-launch/scopes-and-launch-context/index.html#scopes-for-requesting-a-refresh-token" style="color: rgb(65, 131, 196);" class="">HL7 FHIR specifications</a>.</p>
<br class="">
</div>
<div style="font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; background-color: rgb(255, 255, 255);" class="">
Thanks,</div>
<div style="font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; background-color: rgb(255, 255, 255);" class="">
Karl</div>
</div>

_______________________________________________<br class="">Openid-specs-ab mailing list<br class=""><a href="mailto:Openid-specs-ab@lists.openid.net" class="">Openid-specs-ab@lists.openid.net</a><br class="">http://lists.openid.net/mailman/listinfo/openid-specs-ab<br class=""></div></blockquote></div><br class=""></div></body></html>