Vid hämtning av signaturer eller godkännanden från mottagare kräver många avtal en högre säkerhet för autentisering än enkel e-postverifiering. Adobe Sign tillhandahåller flera alternativ för avsändare att infoga en andrafaktorsautentisering i processen, vilket ger en högre förtroendenivå för att dina mottagare är korrekt certifierade.

Funktionsbeskrivning

Identitetsverifieringen av en mottagare är ett nyckelelement för att hämta en juridisk signatur.

Adobe Sign använder e-post som standardmetod för förstafaktorsautentisering, vilket uppfyller kraven på en elektronisk juridisk signatur under ESIGN Act. För många kunder täcker det behoven.

Vissa kunder föredrar dock att lägga till en andrafaktorsautentisering för att tillhandahålla en förhöjd försäkran om att den avsedda mottagaren är korrekt identifierad. För detta ändamål tillhandahåller Adobe Sign flera alternativ att välja mellan, beroende på vilken nivå av försäkran som anses lämplig.

Generellt sett infogar mer robusta autentiseringsmetoder mer "friktion" i signeringsprocessen, så det är administratörens uppgift att ställa in de tillgängliga alternativen som de interna policyerna dikterar så att de är rimliga och lämpliga.

De mer komplexa premiumautentiseringsmetoderna inkluderar ytterligare kostnader per transaktion.

Autentiseringsmetoder för signerare

  • E-post - E-post är standardmetoden för förstafaktorsautentisering av en mottagare
    • Alla tjänstenivåer använder initialt detta som standardautentiseringsmetod
  • Lösenord - Ett alfanumeriskt lösenord som måste anges av signeraren tillhandahålls av avsändaren när avtalet konfigureras
    • Tillgängligt för alla tjänstenivåer
    • Unika alfanumeriska lösenord inställda per mottagare
    • Lösenord exponeras inte i avtalsposterna, och de kan inte heller återskapas när avtalet har skickats
  • Socialt - Signeraren måste autentisera via någon av de tillåtna tredjepartstjänsterna
    • Endast tillgängligt för Business- och Enterprise-konton
  • Adobe Sign-autentisering - Signeraren måste autentisera via Adobe Sign
    • Endast tillgängligt för Enterprise-konton
    • Måste aktiveras från servern av din Success Manager


Autentiseringsmetoder för "Premium"-signerare

Premiumautentiseringsmetoder kan medföra ytterligare kostnader per mottagare. Kontakta din försäljningschef eller Success Manager för detaljer.

  • Kunskapsbaserad (KBA) - Signeraren måste svara på flera på måfå utvalda frågor tagna från offentliga databaser
    • Endast tillgängligt för Business- och Enterprise-konton
    • 50 kostnadsfria autentiseringar per år
      • Ytterligare kostnader per mottagare om fler än de ursprungliga 50 önskas
    • Gäller endast för amerikanska mottagare
  • Telefon (SMS) - En verifikationskod skickas till mottagarens telefonnummer
    • Endast tillgängligt för Enterprise-konton
    • Mottagarens telefonnummer måste anges när avtalet skapas
    • 50 kostnadsfria autentiseringar per år
      • Ytterligare kostnader per mottagare om fler än de ursprungliga 50 önskas
  • Registrerings-ID - Mottagaren måste tillhandahålla ett godkänt statligt utfärdat ID-kort och en selfie
    • Endast tillgängligt för Enterprise-konton
    • Ytterligare kostnader per mottagare som måste aktiveras innan alternativet kan exponeras i användargränssnittet för administratörer


Så här fungerar det

Avsändarens perspektiv

Avsändare kan välja en autentiseringsmetod från en listmeny strax till höger om mottagarens e-postadress.

Listan över tillgängliga alternativ begränsas av administratören, och standardvärdet kan också ställas in (se Konfiguration).

Det är också möjligt att ställa in olika autentiseringsmetoder per mottagare. Detta är särskilt värdefullt om du har interna motsignerare som inte kräver en högfriktionsautentiseringsmetod (som KBA eller regerings-ID).

recipient_list_-uniqueauthentications

Att välja autentiseringsmetod är enkelt. Det är bara att klicka och välja, med två undantag:

  • Lösenordsautentiseringar kräver att avsändaren anger lösenordet (två gånger)
    • Lösenorden är endast alfanumeriska. Inga specialtecken
    • Avsändaren måste kommunicera lösenordet till mottagaren via en extern kanal
    • Observera att lösenordet inte lagras med tydlig text någonstans i applikationen. Om lösenordet förloras, kan det inte återskapas eller återställas. Avtalet kommer att behöva avbrytas och skickas igen
Password

 

  • Telefonautentisering kräver att ett telefonnummer anges för mottagaren
phone_authentication

Signering via e-postautentisering

Signering via e-postlänken är standardprocessen för alla transaktioner. Åtkomst till en e-postlåda är en autentiserad process, så att få tillgång till e-posten är en metod för mottagarvalidering.

Om ingen andrafaktorsautentisering tillämpas öppnas avtalsinnehållet direkt om e-postlänken klickas på, vilket ger mottagaren fullständig åtkomst till dokumenten som skickats för deras granskning.

email_authentication

Obs!

Avtal som är säkrade med andrafaktorsautentisering maskerar dokumentets miniatyrbild.

protected_email

 

Revideringsrapporten registrerar endast en lyckad e-signatur.

email_authenticationauditreport

Signering via lösenord

Signering av ett avtal med ett lösenord installerat som andrafaktorautentisering börjar med e-postlänken.

När länken klickas på presenteras lösenordsgränssnittet för mottagaren.

password_authentication

En e-postlänk tillhandahålls (under avsändarens namn) om mottagaren behöver kontakta avsändaren för att få lösenordet.

Om mottagaren anger fel lösenord fem gånger kommer avtalet att avbrytas.

  • Avsändaren kommer att meddelas att avtalet har avbrutits med ett meddelande om att mottagaren inte kunde ange rätt inloggningslösenord.

När rätt lösenord anges får mottagaren fullständig åtkomst till innehållet.

 

Revideringsrapporten indikerar att rätt lösenord angavs.

password_authenticationauditreport


Signering via social (webb) identitetsautentisering

Social identitetsautentisering (eller "webb") kräver att signerare loggar in på en tredjepartswebbtjänst.

  • Google, LinkedIn och Facebook är standardalternativen, men kontoadministratören kan begära att andra alternativ aktiveras.

Signeraren kan välja mellan de tillgängliga tjänstealternativen:

social_authentication

När tjänsten väljs öppnas ett fönster med tjänstens inloggningsskärm.

Mottagaren autentiserar tjänsten med hjälp av rätt inloggningsuppgifter för tjänsten.

  • Denna process sker helt och hållet inom tredjepartstjänsten. Ingen del av denna autentiseringsprocess sker i Adobe Sign, och inloggningsuppgifterna registreras inte

När en signerare autentiserar rapporterar tjänsten tillbaka till Adobe Sign att autentiseringen har lyckats och att den lyckade autentiseringen har registrerats som en giltig identitetsverifikation.

linkedin_authentication

Visst innehåll skickas vid den här tidpunkten tillbaka till Adobe Sign för att uppdatera revideringsrapporten. Till exempel infogar LinkedIn värdet Namn från kontot i signaturfältet och placerar en länk i revideringsrapporten som pekar på den autentiserande LinkedIn-profilen.

social_audit_report


Signering via Adobe Sign-autentisering

För Adobe Sign-autentisering måste signeraren ange sina Adobe Sign-inloggningsuppgifter när avtalet autentiseras.

Den här processen liknar den sociala autentiseringsmetoden ovan, men det enda alternativet för autentisering är Adobe Sign. 

  • Detta är mycket användbart för interna autentiseringsprocesser där du vet att mottagaren har ett Adobe Sign-konto
  • Om mottagaren inte har ett Adobe Sign-lösenord måste hen registrera sin e-postadress (för att skapa ett lösenord) innan hen kan komma åt avtalet
adobe_sign_authentication

Som standard infogar autentiseringspanelen mottagarens e-postadress.

  • Du kan kontakta din Success Manager för att ändra denna standard till att lämna e-postfältet tomt.
adobe_sign_authenticationgump

Revideringsrapporten indikerar klart och tydligt att mottagaren verifierafes med Adobe Sign-autentisering.

adobe_authenticationauditreport


Kunskapsbaserad autentisering

Kunskapsbaserad autentisering har en hög verifieringsnivå som främst används av finansiella institutioner och vid andra tillfällen då det är mycket viktigt att kunna bekräfta signerarens autenticitet.

Signeraren uppmanas först att ange personlig information som KBA-applikationen använder för att samla in flera anpassade, icke-triviala frågor från signerarens förflutna (med hjälp av offentliga databaser). Varje fråga måste besvaras korrekt för att få åtkomst till avtalet.

Mottagaren har ett begränsat antal försök på sig att svara rätt på frågorna, annars avbryts avtalet och avsändaren meddelas.

Adobe tillhandahåller den här funktionen via ett samarbete med InstantID Q&A från LexisNexis Risk Solution.

Läs mer om LexisNexis Identity Verification.

kba_authentication

 

Lyckad KBA-identitetsverifikation loggas i revideringsrapporten, inklusive autentiseringstoken från Lexis Nexis.

kba_authenticatedauditreport


Telefonautentisering

Telefonautentisering levererar en femsiffrig kod till mottagarens mobiltelefon som måste anges för att avtalet ska exponeras.

  • Telefonnumret måste anges under skapandet av avtalet
  • Om mottagaren delegerar sin signaturbehörighet kommer han eller hon att bli ombedd att tillhandahålla ett giltigt telefonnummer för den nya mottagaren. Ett korrekt telefonnummer måste anges, annars kommer autentiseringen att misslyckas
  • Mottagaren har möjlighet att välja ett textmeddelande (för smarttelefoner som kan ta emot textmeddelanden) eller ett röstsamtal (om ingen telefon som kan ta emot textmeddelanden finns tillgänglig)
    • Autentiseringskoden är giltig i tio minuter efter att den har levererats
          
  • Endast de fyra sista siffrorna av telefonnumret exponeras.  Om mottagaren identifierar att telefonnumret inte stämmer finns det en e-postlänk under avsändarens namn för att ta kontakt.
phone_authenticationrequest

 

När mottagaren klickar på knappen Skicka kod, uppdateras sidan och åtkomstkoden kan matas in.

  • Mottagaren har fem försök på sig att ange rätt kod.
  • Om mottagaren misslyckas fem gången kommer avtalet att avbrytas och avsändaren att meddelas.
phone_auth_entercode

 

Revideringsrapporten identifierar klart och tydligt att ett telefonnummer användes för verifiering. 

  • Endast de fyra sista siffrorna av telefonnumret exponeras
phone_auth_auditreport


Regerings-ID

Obs!

Regerings-ID finns för närvarande i begränsad version.

Kontakta din Success Manager om du vill diskutera att få åtkomst till den här nya funktionen.

Regerings-ID-autentisering använder en mottagarbild på ett statligt utfärdat dokument, tillsammans med en selfie, för att etablera en stark verifieringspost.

Dokumenten som stöds är:

  • Globalt pass
    • Alla ICAO-kompatibla passböcker
  • Körkort/nationellt ID
    • USA
    • Storbritannien
    • Kanada
    • Frankrike
    • Irland
    • Italien
    • Nederländerna
    • Spanien

När e-postlänken klickas på uppmanas mottagaren att ange ett telefonnummer till en smarttelefon. Detta krävs för bildfångstapplikationen som ska jämföra ID-kortet med den statliga databasen.

  • Det finns en tidsgräns på 15 minuter för att slutföra verifieringsprocessen som startar när e-postlänken klickas på.
  • När textmeddelandet har skickats visas ett blått meddelande som indikerar att meddelandet har skickats, och länken i det meddelandet har en tidsgräns på fem minuter.
gov_id_notificationmessage

 

På smarttelefonen levereras ett textmeddelande med en länk.

När länken klickas på ges mottagaren alternativet att autentisera med antingen körkort/ID-kort eller ett pass.

gov_id_first_steps-400

 

Vid användning av ett körkort eller ett ID-kort kommer appen att uppmana mottagaren att ta en bild av:

  • Kortets framsida
  • Kortets baksida
  • Sig själv

Om ett pass används krävs endast en bild på passet.

gov_id_front_andback-400

 

Under insamlingsprocessen och verifieringen av dokumentinnehållet visar den ursprungliga aviseringssidan ett statusmeddelande om att detaljerna verifieras.

gov_id_verificationinprocess

 

Kortets innehåll skannas och den statliga databasen tillfrågas för att säkerställa att ID-kortet är äkta.

Selfiebilden jämförs därefter med bilden på dokumentet för att ge en realtidsmatchning av mottagaren på dokumentet.

När båda stegen har slutförts framgångsrikt beviljas mottagaren åtkomst till avtalet.

  • Namnet på mottagaren såsom det presenteras på ID-kortet importeras till signaturfältet och kan inte redigeras.
gov_id_success

Mottagaren har fem försök på sig att verifiera med hjälp av sitt ID. Om mottagaren misslyckas fem gånger avbryts avtalet och avsändaren meddelas.

 

Revideringsrapporten indikerar klart och tydligt att mottagaren verifierades med ett regerings-ID.

gov_id_auth_auditreport


Konfigurationsalternativ

Alternativ för allmän åtkomst till autentiseringsalternativ

Några snabba ord om att konfigurera interna mottagare

Det finns två avsnitt med liknande kontroller på sidan Skicka inställningar.

  • Den övre gruppen av kontroller etablerar de "allmänna" åtkomstreglerna.
  • Den nedre gruppen gör det möjligt att tillämpa en annan regeluppsättning på dina "interna mottagare"
    • Interna mottagare definieras som mottagare (e-postadress) inom ditt Adobe Sign-konto
      • Notera att detta inte nödvändigtvis inkluderar alla personer i ditt företag.
      • Mottagare i ett annat Adobe Sign-konto ses inte som "interna" av applikationen, även om de tillhör ditt företag och delar din e-postdomän.

Att konfigurera interna mottagare med en annan autentiseringsmetod (t.ex. Adobe Sign-autentisering) har fördelar:

  • Mindre frustration för dina signerare
  • En mindre komplex signeringsprocess snabbar på signeringen för mottagare som kanske måste motsignera flera avtal.
  • Kostnaderna för premiumautentisering kan undvikas

 

Allmänna åtkomstkontroller

Det finns tre allmänna åtkomstkontroller:

  • Kräv att avsändare specificerar en av de aktiverade autentiseringsmetoderna - När detta aktiveras kommer E-post att tas bort från listan med autentiseringsmetoder. En av andrafaktorsautentiseringsmetoderna måste användas.
    • Du måste välja en standardautentiseringsmetod
  • Som standard, använd följande metod - Etablerar standardmetoden som infogas när en mottagare läggs till i ett avtal
  • Låt avsändare ändra standardautentiseringsmetoden - Om detta är aktiverat kommer avsändaren att ha möjlighet att välja valfri aktiverad metod från en rullgardinslista
    • Om det är inaktiverat kan endast standardautentiseringsmetoden användas
Controls

 

Kontroller för interna mottagare

Det finns också tre kontroller relaterade till interna mottagare:

  • Aktivera olika identitetsautentiseringsmetoder för interna mottagare - När detta är aktiverat kommer interna mottagare att tillämpa olika autentiseringsregler
  • Använd följande metod som standard - Etablerar standardmetoden för interna mottagare
  • Låt avsändare ändra standardautentiseringsmetoden - Beviljar avsändaren behörighet att ändra standardautentiseringsmetoden till annat alternativ som aktiverats av administratören

Lösenordalternativ

Lösenordt för avtalssignering har tre kontrollalternativ som kan konfigureras av administratören på sidan Säkerhetsinställningar:

  • Begränsa antalet försök - Aktiverat som standard. Om detta är inaktiverat kan mottagare försöka att ange lösenordet ett obegränsat antal gånger
    • Tillåt signerare XX försök att ange avtalslösenordet innan avtalet avbryts - Administratören kan ange ett valfritt antal för att begränsa antalet autentiseringsförsök. När antalet försök överskrids kommer avtalet automatiskt att avbrytas och avsändaren att meddelas
  • Lösenordsstyrka för avtalssignering - Definierar komplexiteten hos lösenordet som måste anges när avsändaren skapar avtalet

Obs!

Alternativen som konfigurerar säkerhetsinställningarna är endast synliga om autentiseringsmetoden är aktiverad på sidan Skicka-inställningar.

agreememnt_passwordsettings

Sociala alternativ

Som standard är endast tre webbidentitetsalternativ tillgängliga:

  • Google
  • LinkedIn
  • Facebook

Enterprise-kunder kan be sin Success Manager att aktivera något av alternativen nedan:

  • Yahoo
  • Twitter
  • Microsoft LiveID

Adobe Sign-autentiseringsalternativ

Som standard infogar Adobe Sign-autentiseringsmetoden mottagarens e-postadress i autentiseringsfönstret.

Om så önskas kan din Success Manager inaktivera denna automatiska ifyllning, och lämna e-postfältet tomt för mottagaren att fylla i.

KBA-alternativ

Kunskapsbaserad autentisering har tre konfigurerbara alternativ som kan hittas på sidan Säkerhetsinställningar:

  • Begränsa antalet försök - Aktiverat som standard. Om detta är inaktiverat kan mottagare försöka att autentisera ett obegränsat antal gånger
    • Tillåt signerare XX försök att validera sin identitet innan avtalet avbryts - Administratören kan ange ett valfritt antal för att begränsa antalet autentiseringsförsök. När antalet försök överskrids kommer avtalet automatiskt att avbrytas och avsändaren att meddelas
  • Svårighetsnivå för kunskapsbaserad autentisering - Definierar valideringsprocessens komplexitet:
    • Standard - Signerare får 3 frågor och måste svara rätt på alla frågorna. Om de endast svarar rätt på 2 frågor kommer de att få 2 frågor till och de måste då svara rätt på båda dessa frågor
    • Hård - Signerare får 4 frågor och måste svara rätt på alla frågorna. Om de endast svarar rätt på 3 frågor kommer de att få 2 frågor till och de måste då svara rätt på båda dessa frågor

Obs!

Alternativen som konfigurerar säkerhetsinställningarna är endast synliga om autentiseringsmetoden är aktiverad på sidan Skicka-inställningar.

kba_authenticationsecuritysettings

Telefonalternativ

Telefonautentisering gör det möjligt för administratören att konfigurera antalet tillåtna försök innan avtalet avbryts.

Den här inställningen kan konfigureras på sidan Säkerhetsinställningar

Obs!

Alternativen som konfigurerar säkerhetsinställningarna är endast synliga om autentiseringsmetoden är aktiverad på sidan Skicka-inställningar.

phone_authenticationsecuritysettings

Obs!

Telefonautentisering ger användaren möjlighet att anpassa SMS-meddelandet och infoga företagsnamnet från avsändarens profil istället för "Adobe Sign". Se här för mer information

Alternativ för regerings-ID

Obs!

Regerings-ID finns för närvarande i begränsad version.

Kontakta din Success Manager om du vill diskutera att få åtkomst till den här nya funktionen.

Åtkomst till regerings-ID-autentisering kräver att ett kontrakt finns på plats för en specifik årlig volym av mottagare. Tills detta har konfigurerats på servern kommer alternativet inte att vara synligt i gränssnittet för administratörer.

Antalet lyckade försök för att verifiera identitet är satt till fem som standard.  Detta antal kan justeras upp eller ner på begäran till din Success Manager.


Gör så här för att aktivera och inaktivera

Standardprocessen för e-postverifiering för standardavtal kan inte inaktiveras via användargränssnittet. 

Widgetar är undantaget (se nedan)

Enterprise-kunder kan utforska kreativa metoder (såsom API:t) med sin Success Manager för att kringgå autentiseringsmetoderna om de har en process för att uppfylla autentiseringskraven.

Andrafaktorsautentiseringsmetoder aktiveras eller inaktiveras via gränssnittet för administratörer: Kontoinställningar > Skicka-intällningar

nav_to_identify_authenticationmethod


Inaktivera e-postverifiering för widgetar

Widgetar används i en mängd unika användarfall, och ofta finns det en minskad efterfrågan på starkt tillämpad mottagarautentisering.  

För konton som inte behöver autentisera widgetsignaturer kan alternativet att inaktivera e-postverifiering konfigureras genom att gå till: Kontoinställningar > Signaturegenskaper > E-postverifiering för widgetar

Obs!

Den här inställningen inaktiverar endast e-postverifieringen av signaturen.

  • Den här inställningen tillämpas på alla widgetar inom kontot eller gruppen där inställningen definieras.

Om ett lösenord aktiveras för att bevilja åtkomst till widgeten, påverkas inte säkerhetsgrinden.

disable_widget_identity

Denna produkt är licensierad enligt en Creative Commons Erkännande-Ickekommersiell-Dela Lika 3.0 Unported-licens  Twitter™- och Facebook-inlägg omfattas inte av villkoren i Creative Commons-licensen.

Juridiska meddelanden   |   Onlinesekretesspolicy