Switching to Rest API from SDK- sessionToken

Hi Randy,

Thanks for your post! For your questions:
(1)The SDK function to generate a "session token" was kind of a old fashion to build an an-person signing link. Check the two methods mentioned in this developer blog for the latest practice:
https://www.onespan.com/blog/onespan-sign-developer-person-signing

(2)First of all, if you want to suppress outbound email notifications for in-person use cases, you could contact support team ([email protected]) and turn on an account level setting "Disable InPerson Activation Email".

Because in-person transaction, by its nature, allows the signers to both sign remotely or on-site. If you want to handle both scenarios with in-person transaction, you'd invoke an additional API to notify signers when its remote signing scenario. On the contrary, you could also create remote vs in-person transactions to handle both scenarios, as long as you can make the decision prior to package creation.

(3)For your reference, whether a package supports in-person signing determines by a package level settings, see below:

{ "name": "In-Person Signing Transaction", "language": "en", "description": "In-Person Signing Transaction", "status": "DRAFT", "settings": { "ceremony": { "inPerson": true } } }

Duo

Thank you. Very helpful. Some follow-ups:
 

1) our current account is being used for in-person and has Disable InPerson Activation on. So no emails are sent. I don't see anything in our code (old SDK) that indicates inPerson =true. But yet we are doing in-person signing. Unfortunately, our package is created and sent before the point where the user would decide on remote or in-person. Does the "inPerson:True" break remote signing? I guess I'm wondering what that flag actually does, since doesn't control email sending.

2) What is the practical difference between /api/authenticationTokens/signer/multiUse and singleUse ? Does that mean the user can start again if they close their browser for multiUse and not for singleUse?

Thanks, Randy

Hi Randy,

For your questions:

(1)I would understand "inPerson:True" as "support in-person signing" rather than "force to launch as in-person signing" - as I mentioned above, in-person transaction supports both remote and on-site signing scenarios. (In-person signing is where you will see a dropdown list with signer names (in old signer experience) or a welcome page with recipient list (in new signer experience), which allows you to switch between signers and complete signing for all signers within one signing ceremony. You can only launch this mode by turning on inPerson:true)

If you don't see anywhere in the code mentioned about in-person, it might be the case that the default package setting has been turned on in-person - this needs to be verified against support team.

(2)You assumption is correct! Once the link built by a signer authentication token has been accessed  - the signer auth token was used to exchange for a session token - a single-use signer auth token will no longer be valid while a multi-use signer auth token still is.

Duo