cpomeroy | Posts: 19

question about locked signers and in-person signing

Monday, March 13, 2017 at 07:23am
0 votes
Hi, We've discovered some behaviour that seems strange/inconsistent to our team. It may just be a case of not understanding the APIs properly, but either way hopefully you can help us out. Our application supports both remote and in-person signing. What we've discovered is that if we created a session token for in-person signing using a locked signer, then the resulting in-person ceremony is locked (just like if the signer were signing remotely). However, if we create and open the ceremony using the sender as the owner of the session token then we can switch to the locked signer, and the locked signer is not locked. This seems a little inconsistent to us. Should remote signers who are locked be able to participate in in-person signing ceremonies? Here's the code we use to create the session token: SessionToken sessionToken = eslClient.getSessionService().createSessionToken(docPackage.getId().getId(), signerId); Thanks in advance, -Chris
mwilliams | Posts: 957

Reply to: question about locked signers and in-person signing

Monday, March 13, 2017 at 06:13pm
0 votes
Hey Chris, In general, I would probably say this is okay and probably done intentionally as when you enable an in-person ceremony, it's generally assumed that everyone is in the same room and you can verify the identity of all signers. In the case of a remote signing session being locked out, the person entered authentication information incorrectly and you cannot verify in-person who they are since they are remote. So, if they're locked, it's possible they've been compromised so you wouldn't want a session opened that's starting from them. Just my thoughts. I will check with some other folks in the morning and let you know.
cpomeroy | Posts: 19

Reply to: question about locked signers and in-person signing

Tuesday, March 14, 2017 at 10:42am
0 votes
Hi Michael, Thanks (as always) for the quick response. I agree that the existing behavior does make sense from a workflow perspective, but I found it strange that even if I open the iFrame using "Signer 2" (as opposed to the package owner) and switch to "Signer 1" (who's locked), I can still sign. So it's not making any decision based on my position as the package owner. I guess I expected switching signers to perform the equivalent action of changing the owner of the session token. So either opening as "Signer 1" should assume that I'm in-person so it's ok to sign, or switching to "Signer 1" should recognize that I'm locked and continue to keep me locked out. It seems inconsistent. Appreciate you offering to check with some other folks today. Please let me know when you've confirmed this. Cheers, -Chris
mwilliams | Posts: 957

Reply to: question about locked signers and in-person signing

Tuesday, March 14, 2017 at 11:15am
0 votes
Hey Chris, Not a problem at all. I actually just heard back as I was typing this. Essentially, what I said is confirmed. When accessing remotely, the only person that an in-person selector will appear for is the Sender. Otherwise, in-person sessions have to be created by the API. So, with that kind of limitation, the person creating the code would have the control over creating that session, so this shouldn't arise as an issue. In the event that the signer had gotten locked out, you could always make unlocking the signer as part of the process if the in-person session will be created with their ID. In any case, the reasoning is that you have complete control over the in-person session creation as the sender/API key holder, so this should not cause any problems. Hope this helps.

Hello! Looks like you're enjoying the discussion, but haven't signed up for an account.

When you create an account, we remember exactly what you've read, so you always come right back where you left off

LoginSign Up