For the most important transactions in life,
we are oftentimes asked, can I see your ID?
As these sensitive transactions are moved online,
validating users' ID is critical.
Join us today as we talk to Josh Wise about the DocuSign
identification platform on this episode of Developer Deep Dive.
[MUSIC PLAYING]
Hi, my name is Matthew Roknich, a developer evangelist
at DocuSign.
I'm here in the DocuSign studio with Josh Wise, who's
a senior engineering manager responsible for auth
and identity.
Josh, it is great to have you on the show today.
Hi, Matt.
Thanks for having me.
So Josh, all this work on authentication and identity
is incredibly exciting, internally.
Can you tell us more about DocuSign Identify?
Sure.
So DocuSign Identify refers to our whole family
of identity and auth products.
It's basically a product family that
encompasses all of our offerings to solve the business problem
of automating identification.
So it includes things like SMS or phone,
round-tripping of a code, knowledge-based authentication,
ID check over a video camera for European qualified signatures,
third-party custom-built solutions
for customers' own custom needs, as well as
our new ID verification product that we built ourselves.
Underneath all of that is what we call the DocuSign Identify
platform, which is an open set of APIs
and a protocol that allows customers to build
their own custom identity solution,
as part of login to DocuSign envelopes.
We built DocuSign ID verification
on top of this platform as our first integration.
Great.
So what really prompted-- what was
the inspiration behind this investment in identity
solutions?
So customers in the past, in non-US markets,
had a lot of trouble being able to adopt e-signature solutions,
due to different government regulations,
like eIDAS, which is an EU-wide legal framework governing
e-signatures.
For example, in France, you have to use an electronic ID
in order to-- before you could apply an electronic signature
to send documents.
So with the Identify platform, developers in different parts
of the world can legally integrate our agreement cloud,
even if they have custom identity needs.
Excellent.
So to that end, how can developers
get started using this platform today?
So there's basically two solutions you could do.
You could either, if you have a custom scenario that you need
to build, you could build a custom identity
or challenge for your signers to go through.
Or you could use the DocuSign-built identity
solutions, like DocuSign ID verification
through the e-signature API today.
And we'll dig into the second one of those, the ID
verification piece, because I don't know if we'll have time
to show the whole protocol.
Great.
So when an envelope is sent with ID verification enabled,
a recipient will receive an email notification
for DocuSign, but before she can access the document,
she'll be prompted to verify her identity by uploading a copy
or taking a photo of her government-issued ID,
so for this example, a driver's license.
ID verification also supports passport and European eIDs.
It analyzes ID features, such as security markings, watermarks,
to ensure validity.
It also confirms the name on the ID
matches the name on the agreement.
Once their identity is verified, you're
allowed to proceed and complete the remainder of the agreement
process.
Perfect.
So for which countries is this feature available?
So it depends on the ID type.
We support photo IDs and passports, electronic IDs,
and smart cards.
So for driver's licenses and photo IDs,
it's France, Canada, the UK, and the US.
For electronic ID, it's Denmark, Finland, the Netherlands,
Norway, Sweden, and Belgium.
And for smart cards, it's Belgium, Brazil, Estonia,
and Germany.
That is quite a few different combinations, which is awesome.
We're working on building out more also.
Perfect.
So let's just focus in on just the photo IDs for today.
So what exactly is being verified on those IDs?
So there are checks done to make sure the ID isn't expired
and that the name that comes off the ID
matches the name of who the person is supposed to be,
specified by the sender.
There's checks to make sure that the MRZ--
the barcode or machine readable zone,
like QR code looking thing--
the information on that matches the information
on the front of the ID, that the visual features in the ID,
like holograms, match what they're supposed to,
so it doesn't look like a piece of paper,
and that there's no evidence that the text has
been tampered, so like the font matches
across the front of the ID.
It doesn't look like you changed it in Photoshop or something.
Got it.
On the topic of tampering, I know the dev community
is very sensitive to PII leaks.
Do we store these IDs?
No.
We toss them away at the end of the transaction.
They're just in memory for processing.
Excellent.
Any other default limitations of IDV for our dev community
to know?
So ID verification is available in demo
to build API integration today.
It's not enabled by default. It's
only internal enablement today.
So after creating a demo sandbox account,
you'd have to contact a DocuSign account manager or partner
account manager to enable it.
In the future, we'll have these solutions available
for self-service.
We don't have that available yet.
Perfect.
So assuming that our developer has talked to their account
manager and turned on IDV in their demo account,
can you show us a demo of what would be a next step for them?
Yeah.
So I have a couple Postman requests here, so ahead
of this, I have obtained my auth token.
I've logged in.
And I'm using the DocuSign e-sign Postman collection.
So this request here is just a GET request
to accounts, my account ID, and identity verification.
This will show me, if I send this, all of the identity
workflows that this account has access to, to send--
to attach to its recipients, in order
to do identification in front of access to envelopes.
So this is our test account in demo,
so it has a bunch, because we test a bunch of scenarios.
The one that I care about here is DocuSign ID verification,
which is our out-of-the-box ID verification solution that we
talked about.
These identity workflows are what
represent those set of ID configurations,
as to-- that will be self-service in the future,
that will define what types of things
you can have your recipients go through.
So if I grab that ID and I come over here,
and I want to create an envelope,
I'm going to post to my account slash envelopes.
This will look familiar to anyone who's sent envelopes
through the e-sign API before.
So I'm going to send and create in the same call.
I just have a PDF here, email, subject.
I only have one recipient.
It's a signer.
That's me, so I'll be able to see the email.
I have this workflow ID that I grabbed
earlier that will cause me to go through ID verification.
So if I send this request, I will
see that an envelope was created and sent.
So if I come over to my inbox, I should get an email.
And if I follow the link in this email,
you'll see the screen that we saw earlier.
You'll see that I'm prompted for ID verification
before I could access this envelope.
Excellent.
Very cool.
So as a next step for developers watching this video,
where should they get started with IDV?
So there are some resources available on the DocuSign
developer center specific to ID verification.
And to get started, there is a link in the description.
Very cool.
Well, Josh, thank you so much for being a part of the series
and being on the show today.
Thank you.
And that's all time we have, so join us next month
when Lauren Dunn talks to Fred Wade
about customizing e-signature functionality
from within Salesforce, using our Apex tool kit.
If you like that video, be sure to subscribe
to our channel for the latest DocuSign developer content.
If you want to see a specific topic in a future video,
comment below.
For everything else, visit the DocuSign developer center.
[MUSIC PLAYING]