Re: [credential management] Cross-origin credentials (was: Identity Credentials API Extension)

I think we are finally having the conversation that is 45 days over-due.

Again, not speaking for the Credentials CG but rather as someone that has
had experience dealing with a variety of existing federated identity
patterns, I would describe the problem domain as such:


   1. When a user authenticates themselves to an IdP there is an
   opportunity for that IdP to provide them with a set of credentials that are
   issued by that IdP or some other issuer that was part of the federation
   flow they just followed.
   2. The user's browser is then normally redirected to a relying party
   with those credentials in tow and the RP has the opportunity to evaluate
   the credentials and make authentication and authorisation decisions based
   on their content.
   3. For many RPs, the choice of IdP made by the user is not material.
   They just want an authenticated session and usually some attestation/claim
   of a handful of credentials (username, email address).
   4. While many of the federated identity protocols are standardised, few
   user's are aware that their identity at many IdPs can be used in a
   standardised protocol as a means to register/login on RP sites. How many
   user's know that if they have a Gmail account they can simply type their
   email address in to any sign-up form asking for an OpenID? How many people
   know that Facebook supports WebID? Close to zero.
   5. As a result the RP is still forced to present the user with a login
   screen that is plastered with IdP logos (the Nascar problem), the obvious
   result being that RP's gravitate toward a smaller list that consists of the
   most popular super-providers and the network effect is, in contrast to your
   assertion that user privacy is well protected; these super-providers are
   privy to almost everything their user's do online.

When I first read the Credentials Management API spec and saw the
FederatedCredential I mistakenly assumed we were solving this problem. I
imagined there'd be a flow like this:

   1. When a user authenticates themselves to an IdP there is an
   opportunity for that IdP to provide them with a set of credentials that are
   issued by that IdP or some other issuer that was part of the federation.
   The IdP is also able (through the Credential Management API) to store those
   credentials in the browser.
   2. When the user visits a RP site the site queries the Credential
   Management API for credentials it can use to authorise a user to enroll on
   the site.
   3. The user is prompted with a list of credentials that have been stored
   by their various IdPs, and match the type(s) requested by the RP, and given
   the opportunity to select which credentials they wish to share with the RP
   site.
   4. The approved credentials are the results returned to the RP site by
   the API and, if they are sufficient, the RP site uses them to authorize the
   user (which may still involve redirecting the user to the original IdP).

The result is a far more seamless flow for users and the ability for RP
sites to support an infinite number of credential types and federation
protocols without compromising their user's login/sign up experience. Under
such a system a "login with FIDO" button would be unnecessary because the
negotiation of whether a FIDO token is supported by both parties happens
via the API.
So, to answer your question, the type of cross-origin I mean is the type
where an IdP from origin A can store a credential in the browser and that
credential can be returned as the result of a query executed against the
API by a RP from origin B (assuming the necessary user mediation).

Some brief comments in line:

On 29 May 2015 at 22:37, Brad Hill <hillbrad@gmail.com> wrote:

> Let's define what cross-origin means here, as it is itself an overloaded
> term, and perhaps that is at the root of some of the difficulties here:
>
> Cross-origin might mean:
>
> 1) Providing a pointer to another origin where the user will complete some
> part of an authentication ceremony.
>
> Cross-origin information exchange in this model may be mediated through
> the browser with POSTs, redirects, or message channels, but the
> authentication protocol is built entirely out of those generic web platform
> features with no special exceptions to web privacy and security invariants.
>   An example of this is the browser remembering a hint like "this is my
> OpenID identifier" or "I use Facebook to login at this site."  These
> identifiers might be linkable across origins, or a federated provider might
> send the same claims to multiple relying parties, but the ceremonies that
> control this disclosure are directly between the user and the application,
> not mediated through browser chrome or special purpose features.
>

This is roughly what the current API proposes to do except that it does
propose mediation through browser chrome so it begins to look like 3
without the ability to share credentials across origins.


>
> An advantage the proposed API can provide over cookies for this use case
> is that a browser or third-party manager may have shared state orthogonal
> to the cookie store.  e.g. I can log into Firefox, Chrome or LastPass on a
> brand new device and it can synchronize that state for me in a manner in
> which it would not be appropriate to simply copy cookies across devices, or
> I can clear my cookies for siteX to avoid it tracking me while logged out,
> but still have the user agen,t which acts in my interests and under my
> control, assist me in logging back in.
>

So the only advantage the API provides over cookies is the ability to
synchronise state across multiple devices?


>
> 2) A logical provider of authentication assertions under control of the
> user that is shared among multiple origins but which does not share data
> across origins.
>
> An example of this kind of "cross-origin" system might be a FIDO token
> that can be used to log into many sites, but which provides unique and
> unlinkable credentials to each origin.  Or an OTP / code-generator app like
> Google Authenticator or DUO Mobile with a single user ceremony and logical
> identifier but per-origin privacy and state.  Again, these systems do not
> have any special exemptions to existing web security and privacy
> invariants. (although, as in the case of FIDO, such a system might rely on
> the user agent to give it a trustworthy indication of the origin it is
> communicating with)  No user data flows across origins.
>
> It seems reasonable to target an extensibility API to include these in
> scope for a v1 API, but they often have proprietary APIs that are tightly
> coupled to application implementations, and may have out-of-band
> information flows or multiple round trips that are costly to model in an
> abstract API.  (e.g. FIDO defines local APIs to communicate between the DOM
> and an authenticator, mediated by the browser, but doesn't define any
> standard way to express a "login with FIDO" button or even network
> transports for the protocol messages)
>

If the API supported the notion of a credential, that was not stored by an
RP site, being returned in the results of an API query by that RP then the
FIDO use case is very elegantly dealt with. A future extension of the API
may define a HardwareTokenCredential that is stored by the user through
some enrollment process and any RP that supports this type of credential
will include it when they query for credentials from the API. If the user
authorises the browser to share this credential with the RP they are
prompted to follow whatever steps are necessary to populate the hardware
token with a value before it is shared with the RP.


>
> 3) A logical provider of authentication assertions under control of the
> user that has multi-origin scope but shared state.
>
> An example of this would be a traditional PKI client certificate, which
> could be sent to any site, but which identifies the user with assertions
> that are persistent identifiers which can be trivially cross-linked by
> anyone to whom they are sent.  The experience is mediated by the browser
> (but in a way that no web property really likes because they can't control
> it) because it happens at the transport layer and violates the typically
> expected privacy invariants of the web.   Client certificates are
> particularly bad because without renegotiation they also leak linkable,
> private data to passive network observers.
>

Is the ability of a variety of RP sites to collude and establish links
between private user data more or less damaging than pushing users to rely
on a small set of super-providers for identity and for these IdP's to have
all of the information about what RP sites the user visits and what
credentials were shared with those sites.

The existing monopoly on IdP services by a small group of super-providers
is the greatest threat to user privacy on the Web today so the argument
against "PKI client certificate"-like systems on the basis of link-ability
of private data is pretty hollow.


>
> This is starting to get closer to what the Credentials CG is thinking of
> in terms of durable assertions attested by 3rd parties about a user.  It is
> also more difficult to deal with because of the necessary browser mediation
> to manage invariant violations.  Lots of people like public key
> authentication, but not many people like a browser-mediated UX they can't
> control or customize, and the privacy properties of legacy client certs are
> also troublesome.   This stuff has been around for almost 20 years with
> plenty of attempts to make it better and very little success.
>

I agree that the browser mediated UX is probably the biggest culprit in the
poor adoption of client cert based systems however the Credentials
Management API is also proposing that browsers provide some UX mediation,
in a way that conflates credentials with identities.


> Platforms that look like (1) have found much more adoption because relying
> on the user agent to mediate and execute a protocol is just not that
> attractive at scale.  Both ends of the transaction lose the ability to
> rapidly iterate, A/B test and improve on their ceremonies with the user,
> and to upgrade protocols and versions at their own speed.  If site A trusts
> credential provider B to send an assertion and there is a need to upgrade,
> A and B can upgrade, can apply mutual incentives to do so on a coordinated
> and expedited schedule (even for many-to-many relationships), and things
> work for all users as soon as they do.  When you involve a user agent, now
> every user has to upgrade, too, and the applications have to support many
> inconsistent (and possibly insecure) versions across a long tail of browser
> upgrades.  Even the largest application providers don't tend to find this
> to be a tractable problem or a good use of their resources.
>

As above, the API currently prescribes the use of browser chrome to select
a credential (although in this case it is a credential by name but in
reality it is an identity). I agree that this is not ideal for the very
good reasons you have stated but how else can a browser support users that
wish to reuse a federated identity across multiple RP sites and RP sites
that don't want to have a log in/sign up page that looks like a Nascar?


>
> 4) Then we come to the class of cross-origin credentials with Linked Data
> that Manu's doc and Dave's comments seem to describe.  Cross-origin data
> flows that are exceptions to Web privacy and security invariants (and
> therefore require mediation through the browser for user consent), querying
> and discovery cross-origins, aggregation of assertions from multiple
> origins into composite credentials (greatly complicating the required
> browser mediation), assertions containing durable and linkable data
> (potentially transiting over insecure or at least TBD-but-not-HTTPS with
> Web PKI identity), and key parts of the protocol (cryptographic operations)
> that have to be implemented by the user agent.
>
> This is a completely different beast than anything that exists today and I
> think there is no good reason to even try for a common API since there will
> be no clients of such an API that won't a-priori know which system they
> want to interact with.  At that point it is a matter of basic secure design
> to limit unnecessary abstraction and have the most economic and appropriate
> mechanisms for each.
>
>
> What kind of cross-origin do you mean?
>
> On Fri, May 29, 2015 at 2:04 AM Adrian Hope-Bailie <adrian@hopebailie.com>
> wrote:
>
>> Hi Brad,
>>
>> Please ignore the Credentials CG Use Cases for the purposes of this
>> thread, I have purposefully not referred to them as I think they are a
>> distraction from the point I am trying to address; cross-origin
>> credentials.
>>
>> Irrespective of whether the Credentials Management API considers the
>> Credentials CG use cases or not, publishing an API that purports to support
>> federated login but is limited to same-origin use is damaging to any
>> further work from any group that wishes to truly support federated login,
>> identities and/or credentials.
>>
>> The scope of the discussion over the last 45 days has been wide (and
>> largely distracted by two points that you are focusing on, using identities
>> as opposed to credentials and the use of linked-data) but what has not been
>> addressed from anyone in WebAppSec is support for cross-origin credentials.
>>
>> There has been no indication as to why this is explicitly out of scope or
>> how it may be dealt with in future extensions. It has simply been taken off
>> the table with no explanation that I have seen.
>>
>> As I said before, the "FederatedCredential" as defined by the API is not
>> a credential, it's a hint and I think defining it as a credential is
>> damaging in that it is misleading and makes it difficult for a true
>> federated credential API to ever co-exist.
>>
>> I have asked this question twice already and had no response, perhaps we
>> can deal with this first and then allow the discussion to follow:
>>
>> In the context of federated login, what value does this API add beyond
>> what is already possible using cookies to remember the federated identity
>> provider that a user has used in the past?
>>
>> Adrian
>>
>> On 28 May 2015 at 21:09, Brad Hill <hillbrad@gmail.com> wrote:
>>
>>> (tl;dr: We have already worked on API convergence for 45 days, and the
>>> more context we get, the less it seems like it is even a good idea, for
>>> either project.)
>>>
>>> Adrian, we've now spent 45 days exploring the topic, and the spec editor
>>> has been extremely engaged during that period.
>>>
>>> To repeat some of the earlier context - participation in the W3C and
>>> adoption of standards produced by it is voluntary.  It is a venue for
>>> communities of interest to self-assemble under a set of mutually agreed
>>> ground rules.  It is a good thing that we can have different communities
>>> doing different types of projects with different scopes.  A chartered scope
>>> is a critical tool to maintain the viability of each community by being
>>> respectful of the time and energy participants invest, and it is a
>>> necessary precondition of participation for organizations that are making
>>> commitments of intellectual property regarding the deliverables of the
>>> group.
>>>
>>> The influence and expertise of the WebAppSec group is nothing more than
>>> what its participants bring to it.  And nothing is stopping any of those
>>> same people from participating in the Credentials CG or a WG chartered out
>>> of it.
>>>
>>> While "cross-origin" credentials sounds possibly reasonable in the
>>> abstract, my exact point in this thread is that the more we explore what
>>> that involves for the Credentials CG use cases, the less it seems like a
>>> good fit for this API, even as an extension.  The clients and scenarios for
>>> the use-cases are fundamentally distinct.  The Credentials CG's
>>> "credentials" are not merely "cross-origin", they are multi-origin, and
>>> involve the aggregation of many different types of asynchronous operations,
>>> with a completely different set of inputs and outputs, totally different
>>> error conditions and necessary error handling, much more extensive browser
>>> UI and mediation for things like cryptographic operations, query
>>> resolution, trust chaining, and selective disclosure.  Along the way there
>>> are also fundamentally new security protocols and methods of establishing
>>> trust involved while crossing origin barriers, including information flows
>>> that would break or modify fundamental invariants of the web security model
>>> without radically new user-experiences in the browser to support them.
>>>
>>> So, I am simply saying, after taking a considerable amount of time and
>>> effort to explore the possibilities desired at the beginning of this
>>> conversation, namely that "these APIs are trying to do substantially
>>> similar things" and "the Credential Management Level 1 API could also
>>> accommodate the Credential CG use cases with some tweaks to the extension
>>> model", I think that both premises are looking false at a very large and
>>> rising probability.
>>>
>>> It seems extremely unlikely that *either* of these very different takes
>>> on "credential management" will be well-served by sharing an API.  I am
>>> sorry if you find this answer disappointing, but I sincerely think it is
>>> for the best for both projects.
>>>
>>> Let's continue discussing naming, since that is a concern we may be able
>>> to find a consensus on. (though I still maintain that any significance of
>>> similar names for APIs with such massive differences in fundamental
>>> features and serving different business goals will be less important than
>>> anyone thinks in the long run)
>>>
>>> -Brad
>>>
>>> On Thu, May 28, 2015 at 3:50 AM Adrian Hope-Bailie <
>>> adrian@hopebailie.com> wrote:
>>>
>>>> Hi Brad,
>>>>
>>>> To be clear, these are my opinions and not a reflection of the Web
>>>> Payments IG or Credentials CG views. I think the chairs of these groups are
>>>> better placed to speak for or on behalf of the groups.
>>>>
>>>> On 27 May 2015 at 19:04, Brad Hill <hillbrad@gmail.com> wrote:
>>>>
>>>>> It seems we are mostly in agreement, then: these are entirely
>>>>> different technologies where only the degenerate use case of "login" is
>>>>> shared.  We've done a lot of work to try to harmonize, but in the end these
>>>>> technologies are going to stand or fall on their own merits.  Where I
>>>>> disagree is that I think the concern that that the adoption of the proposed
>>>>> API here will harm the prospects for the Credentials CG's work are
>>>>> unfounded, and disagree that we need to remove features in order to
>>>>> preserve the turf the CG feels it has staked out.
>>>>>
>>>>
>>>> If the Credential Management API is published in it's current form,
>>>> limited to single-origin while attempting to provide a federated login
>>>> solution, it is not only damaging to the plans of the Credentials CG but
>>>> the idea of federated or decentralised identity and the definition of
>>>> credentials in general.
>>>>
>>>> The API advertises itself as a means to help site owners leverage
>>>> federated identities for their users but I will bet 90% of RP sites that
>>>> implement the API will be surprised to discover that their user's still
>>>> need to follow the same flow they do today to select a federated identity
>>>> provider, from a potentially long list, log in and then enroll on the RP
>>>> site using their federated credentials before the API, at some point in the
>>>> future, is able to give the RP site a hint at which provider the user's
>>>> federated identity originated.
>>>>
>>>> The "FederatedCredential" as defined by the API is not a credential,
>>>> it's a hint and I think defining it as a credential is damaging in that it
>>>> is misleading.
>>>>
>>>> What value does this add beyond what is already possible using cookies
>>>> to remember the federated identity provider that a user has used in the
>>>> past?
>>>>
>>>>
>>>>
>>>>>
>>>>> You have an ambitious proposal that offers fundamentally new
>>>>> possibilities for the Web to both users and application authors, you have
>>>>> an interested community and momentum within that community, I think that
>>>>> you should not worry so much about what we are doing here with this API.
>>>>> If you can succeed in building what you aim to, nobody who is interested in
>>>>> that will consider this any kind of substitute.
>>>>>
>>>>>
>>>> I am not worried. That is a strange (and rather patronizing) choice of
>>>> words.
>>>>
>>>> I am a little disappointed that a group with the influence of
>>>> WebAppSec, a mandate to deal with issues of security on the Web and
>>>> participants from the major browser vendors with the knowledge required to
>>>> deal with this "ambitious" undertaking seems to be hiding behind it's
>>>> charter in an effort to avoid having anything to do with dealing with
>>>> identity on the Web, a topic that is quite obviously a critical component
>>>> of security.
>>>>
>>>> As you say, the Credentials CG are taking on this "ambitious" project
>>>> and all they have asked of WebAppSec is a concession in this API to allow
>>>> cross-origin credentials. Perhaps I have missed it but I am yet to hear a
>>>> strong argument against at least exploring cross-origin credentials as part
>>>> of this API and yet it seems this is already off the table?
>>>>
>>>>>
>>>>> We can bikeshed a bit longer on the name, but I think we are near or
>>>>> at the end of where further engagement on API convergence is in any way
>>>>> productive.
>>>>>
>>>>>
>>>> This seems the likely, albeit rather disappointing, outcome.
>>>>
>>>>
>>>>> On Wed, May 27, 2015 at 4:37 AM Adrian Hope-Bailie <
>>>>> adrian@hopebailie.com> wrote:
>>>>>
>>>>>> Hi Brad,
>>>>>>
>>>>>> From my reading of the communications to date the primary issue that
>>>>>> has been raised by the Credentials CG is the restriction within the current
>>>>>> API to be same-origin.
>>>>>>
>>>>>> The existing FederatedCredential proposal makes no sense if it is
>>>>>> restricted to same-origin use. Federation is, by definition, cross-origin.
>>>>>>
>>>>>> With the same-origin restriction in place, I am unsure what value the
>>>>>> current proposed API adds or what problem it solves. The use case is so
>>>>>> simple, and so close to the existing password-autocomplete functionality
>>>>>> built into most browsers.
>>>>>>
>>>>>> As a user when I visit a site I have logged into before and have no
>>>>>> current session I see a login form with my username and password already
>>>>>> filled in and have the ability to explicitly re-use those "credentials" to
>>>>>> login again. One click and I have achieved the same outcome as this API AND
>>>>>> had the opportunity to do so explicitly. Is this API potentially making
>>>>>> things worse for the user by hiding their control of the login process
>>>>>> behind configuration screens? Also, given that this is a client side API I
>>>>>> see little utility for server technology vendors who already do complex
>>>>>> session management using existing technology.
>>>>>>
>>>>>> Unless WebAppSec considers cross-origin credentials in it's scope I
>>>>>> see little value in this API. On the contrary, I see an API which will
>>>>>> annex the use of the word "credential" in a very narrow use case which
>>>>>> makes a more broad and valuable use case more challenging to implement in
>>>>>> the future AND an API that purports to support federated login but is
>>>>>> unable to solve the biggest usability issue in federated identity; the
>>>>>> ability to filter the providers offered to the user so they are not
>>>>>> presented with a wall of badges.
>>>>>>
>>>>>> Storing usernames and passwords in a same-origin only system makes
>>>>>> sense. Storing any other credentials under such a restricted system
>>>>>> doesn't. I propose that if the API is to be published it is vastly
>>>>>> simplified to only support username/passwords and is renamed to "Password
>>>>>> API" or "Login API".
>>>>>>
>>>>>> Adrian
>>>>>>
>>>>>>
>>>>>> On 27 May 2015 at 05:20, Brad Hill <hillbrad@gmail.com> wrote:
>>>>>>
>>>>>>> I know Mike has gotten quite in-depth on this, and I'm willing to be
>>>>>>> told I'm wrong, but the more I look at the Credentials CG's use cases as
>>>>>>> presented here, the less I'm convinced they are good fit for the
>>>>>>> "Credential Management API Level 1" spec.  Asynchrony is a nice and broad
>>>>>>> abstraction behind which many things can be hidden. BUT...
>>>>>>>
>>>>>>> If use case #1 is: wait locally on a promise to return some very
>>>>>>> finite set of information (username/password or username/federation
>>>>>>> provider pair) that is stored or hopefully cached locally, with the worst
>>>>>>> case being the user has to re-authenticate one time to their password
>>>>>>> manager and fetch them from the cloud.
>>>>>>>
>>>>>>> And use case #2 is: take as input a "query", assess the
>>>>>>> satisfiability of the query against available credentials and providers and
>>>>>>> perform an unbounded set of recursively defined fetching, aggregation and
>>>>>>> cryptographic operations, including queries to some as-yet-unspecified "new
>>>>>>> mechanism where the URLs refer to decentralized network that holds onto
>>>>>>> documents that include decentralized identifiers and public keys" in order
>>>>>>> to resolve them, including possibly having the user perform authentication
>>>>>>> or add new providers and credentials....
>>>>>>>
>>>>>>> Then I just don't see how it is in any way possible or sane to
>>>>>>> expect the same API shape.  The latter case has so many more potential
>>>>>>> failure and timeout cases and places which may require user interaction and
>>>>>>> resolution, you'll either overcomplicate case #1 or never adequately deal
>>>>>>> with the actual necessary complexity of #2.
>>>>>>>
>>>>>>> Even more so, the vast differences here mean there will never be a
>>>>>>> client to the API that calls it in an abstract function without knowing in
>>>>>>> advance which path they expect to be travelled.  Forcing callers with
>>>>>>> clearly different intents into overly-abstracted APIs when there is no
>>>>>>> driving use-case for the commonality is bad design, even if we can find a
>>>>>>> way to make them fit.
>>>>>>>
>>>>>>> I think in particular the use cases desired by the Credentials CG
>>>>>>> will suffer from further trying to achieve commonality here, because the
>>>>>>> APIs will lack the necessary richness and specificity to purpose that are
>>>>>>> required by the innovative patterns you're contemplating.
>>>>>>> <hat=individual>I also believe it is naive to think you can understand what
>>>>>>> the best API shape will look like until all of these moving parts are
>>>>>>> themselves better defined in their success and failure cases.
>>>>>>> </hat=individual>
>>>>>>>
>>>>>>> Additionally, there are fundamental changes to the web security and
>>>>>>> privacy model which are contemplated by the Credentials CG's proposal which
>>>>>>> should be dealt with independently.  Not using HTTPS and inventing an
>>>>>>> entirely new method to locate and establish trust in keys is a huge thing
>>>>>>> in and of itself, as big a thing as has ever been tried in this space, and
>>>>>>> way too big an elephant to hide under the cafe table of this little API.
>>>>>>>
>>>>>>> My current opinion therefore, as chair, is that the proposals on the
>>>>>>> table in the WebAppSec 2015 charter and from the Credentials CG are quite
>>>>>>> different things, which may share some similarities in common naming and
>>>>>>> broad intent, but which neither will benefit technically from further
>>>>>>> efforts to converge.
>>>>>>>
>>>>>>> -Brad
>>>>>>>
>>>>>>> On Thu, May 21, 2015 at 12:21 PM Manu Sporny <
>>>>>>> msporny@digitalbazaar.com> wrote:
>>>>>>>
>>>>>>>> bcc: Web Payments IG, Web Payments CG, Credentials CG
>>>>>>>>
>>>>>>>> Mike, Brad, Dan, and WebAppSec'ers,
>>>>>>>>
>>>>>>>> As promised on Monday, Dave Longley and I have put together an
>>>>>>>> experimental extension spec for the Identity Credentials API, based
>>>>>>>> on
>>>>>>>> the WebAppSec Credential Management API:
>>>>>>>>
>>>>>>>>
>>>>>>>> https://docs.google.com/document/d/1tI0CJ4wAKKPQacrxOmTtl_GQUBeVtbg8e1ZSXs2SWag/edit?pli=1#
>>>>>>>>
>>>>>>>> We followed Section 8.2 "Extension Points" in the CMAPI spec to do
>>>>>>>> so.
>>>>>>>> The document:
>>>>>>>>
>>>>>>>> 1. Starts out by providing an overview of what the Credentials CG
>>>>>>>> and
>>>>>>>>    Web Payments CG/IG would most likely need for their use cases.
>>>>>>>> 2. We then elaborate on more-or-less how the extension would work in
>>>>>>>>    practice, following the guidance given in section 8.2 on how to
>>>>>>>>    write extensions. We provide all algorithms necessary to do a
>>>>>>>>    simple cross-origin credential storage, request and transmission.
>>>>>>>> 3. We close by listing the problems that we see with the current
>>>>>>>>    specification as well as open questions wrt. browser
>>>>>>>> implementation
>>>>>>>>    concerns.
>>>>>>>>
>>>>>>>> At this point, we ask that:
>>>>>>>>
>>>>>>>> 1. The WebAppSec WG Review the extension specification, and
>>>>>>>> 2. Make comments/suggestions either onlist or in the Google Doc, and
>>>>>>>> 3. that Mike West schedules some time to chat with us to answer any
>>>>>>>>    questions that he may have after reviewing the document.
>>>>>>>>
>>>>>>>> We're happy to jump on the next WebAppSec call and present this
>>>>>>>> work if
>>>>>>>> that's deemed helpful to the group.
>>>>>>>>
>>>>>>>> -- manu
>>>>>>>>
>>>>>>>> --
>>>>>>>> Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
>>>>>>>> Founder/CEO - Digital Bazaar, Inc.
>>>>>>>> blog: Web Payments: The Architect, the Sage, and the Moral Voice
>>>>>>>> https://manu.sporny.org/2015/payments-collaboration/
>>>>>>>>
>>>>>>>>
>>>>>>
>>