Re: Credential Handler API Polyfill (video demo)

I think the UX is much better than TLS Certs already - congrats!

Big Milestone...

Have you thought about a Browser Extension mock-up?

Perhaps on mobile; an app?

FWIW: I still like WebID-TLS however IMHO (whether or not FOAF is used) i
think the CERT should denote the device (ie: My Family TV, My Friends TV,
My Phone, etc.) rather than agent:person.  Yet this view has other
implementation related implications that are not necessarily used for every
application of creds. (perhaps also, my thinking is now out of date for one
reason or another...)

Tim.H.

On Tue, 3 Oct 2017 at 01:39 Dave Longley <dlongley@digitalbazaar.com> wrote:

> On 10/01/2017 06:07 AM, Roman Evstifeev wrote:
> > Hm...at the step of storing a passport narrator says that you should be
> > redirected to the credential handler website. The page really looks like
> > handler website (blue page header), but the url really does not change -
> > it still remains the issuer address... This is confusing. Is this just a
> > demo being incomplete yet? Or am I not getting how the process should
> > look like?
>
> What you're seeing there is a "contextual window" which is a new concept
> where it's unclear how browsers will implement. They may end up just
> opening a new tab but it breaks the user out of the flow. Note that
> there really isn't a "redirection" in the sense that the browsing
> context *navigates* to another page. The existing page that launched the
> request must not lose its state.
>
> The polyfill implements this "contextual window" by using an iframe that
> includes a UI message about what's going on above the iframe -- but it
> is true that it's not explicit which site you're on and I agree that's
> an issue. We're ahead of the browser implementations in this space so
> the demo is just trying to guess at what the experience will be in a
> browser or what the "best" experience *could* be.
>
> We're interested in feedback like this -- and suggestions for addressing
> it. Do you think that the user should be taken to an entirely new tab at
> this point (understanding the drawback where the user may "lose" their
> place if they click on other tabs) -- or should we just try to better
> visually include the origin of the wallet/repository site somehow? There
> is also limited real estate on mobile. We do expect that this will be
> easier for browsers since they have control over the chrome.
>
>
> >
> > On 26 September 2017 at 06:19, Manu Sporny <msporny@digitalbazaar.com
> > <mailto:msporny@digitalbazaar.com>> wrote:
> >
> >     Hey Credentials CG (bcc: VCWG),
> >
> >     I think you'll really like this. The engineering team at Digital
> Bazaar
> >     has been hard at work creating a production grade polyfill for both
> the
> >     Credential Handler API in Chrome, Safari, Edge, and Firefox. We're
> doing
> >     this to accelerate uptake of Verifiable Claims and Decentralized
> >     Identifiers. We're announcing a beta release to developers today.
> >
> >     An introductory video giving some background as well as recordings
> >     showing it working in all major browsers can be found here (~6
> minutes
> >     runtime):
> >
> >     https://youtu.be/qdbDu1oV0PI
> >
> >     What does this mean for the Credentials CG work?
> >
> >     * When the polyfill hits production, we expect that ~90% of all
> browsers
> >        (roughly 2.8 billion people) will immediately get support for the
> >        Credential Handler APIs across desktop and mobile browsers.
> >
> >     * Web developers won't need to wait for browsers to implement the
> latest
> >        Credential Handler API in order to deploy to their customers.
> >     Instead,
> >        the polyfill will provide missing browser features until the
> browsers
> >        support them.
> >
> >     * This will enable us to more rapidly test and deploy new
> >        verifiable claims features, greatly reducing the cost of
> >     innovation in
> >        the group, and enabling more people to participate in the design
> and
> >        development process.
> >
> >     * This approach is not only compatible with DID-based authentication,
> >        but empowered by it. You can see it how easy DID-based login is
> >     in the
> >        demo video.
> >
> >     * Since this approach is almost identical to the Web Payments API,
> which
> >        all browser vendors are implementing, there is a high likelihood
> that
> >        this API will be technically acceptable to the browser vendors as
> >        well. We're going to start that conversation with them in the
> coming
> >        weeks.
> >
> >     What is next?
> >
> >     * We'll submit a paper on this to Rebooting Web of Trust for
> >        discussion.
> >
> >     * We'll continue to harden the polyfill for production usage.
> >
> >     * We'll pick an open license that works for all orgs and
> implementers.
> >
> >     * We still need to implement some simple things, like better
> >        animations/transitions when selecting identities/credentials. Some
> >        CSS still needs to be fixed.
> >
> >     -- manu
> >
> >     --
> >     Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
> >     Founder/CEO - Digital Bazaar, Inc.
> >     blog: Rebalancing How the Web is Built
> >     http://manu.sporny.org/2016/rebalancing/
> >     <http://manu.sporny.org/2016/rebalancing/>
> >
> >
>
>
> --
> Dave Longley
> CTO
> Digital Bazaar, Inc.
> http://digitalbazaar.com
>
>