- From: Roman Evstifeev <someuniquename@gmail.com>
- Date: Tue, 10 Oct 2017 13:45:43 +0300
- To: Dave Longley <dlongley@digitalbazaar.com>
- Cc: W3C Credentials CG <public-credentials@w3.org>
On 2 October 2017 at 17:38, 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. Oauth2 flow opens new small browser window on top. This window has url bar, that clearly indicates that I am on the auth provider page, and connection can be trusted, as it is secured by tls. Also this page says what remote site requested which permissions. I find this flow less confusing than using iframe. > 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. Hm, i am not sure what exactly is going on behind the scenes - is the full code example avaliable anywhere? What exactly that page needs to store? Can it be passed around in callbacks, as oauth2 does? > > 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
Received on Tuesday, 10 October 2017 10:46:07 UTC