Obfuscating certain documents fields varied by signer/role

Hi Randy,

 

Yes, with OneSpan Sign Label field, it will only display the value to the signer whom it binds to and hide it from other signers. However, two points which might be slightly different from what you were expecting #1 other signers won't see the fields that are binding to other signers, not to obfuscate the data (it's kind of a general rule in OSS) #2 label field value will be stamped to the signed document once the signer signed, so the signing index might also come to your concern.

 

Duo

I'm not clear on binding. Though we use it in our (very) old SDK implementation. 

1) I'm not exactly sure what it does for us today. That is something I need to understand. 

For us, it seems to tie signature to date fields. 

we create a field with type SIGNATURE and subType FULLNAME (or INITIALS)
and then create another field type INPUT and subType LABEL and .setBinding("{approval.signed}"). This is associated with a date field but I don't understand how it knows the INPUT LABEL is a date field (?). And is it that the two fields are in the same approval that connects them?

After that it puts both in the same approval connected to a role, and it seems the date field is updated when it's the signature field is signed. 

2) Besides knowing what it is doing today for us, I need to understand the Rest API equivalent. Is there something more in depth. I used the sample to send the package and document, but it didn't do much with binding.

3) If the binding of a fileld to a signer will hide a field from other signers, I'm not sure this is a solution for hiding in my scenario. But I would like to understand it better. I hope the result of 1 and 2 will help me with that. 

Thanks again,

Randy

Hi Randy,

 

For your questions:
(1) Yes, both fields are under the same approval and that's how the signing date field knows when the signer clicked to sign.

Talking about the field type, all of the "type", "subtype" and "binding" them together determines the field type:

-If a field has "binding" attribute, it means its value will be automatically calculated based on the signer information (e.g. signer title, signer name) or signing information (e.g. signing date).

-On the contrary, if a field has "binding" value as null or doesn't have the binding attribute, it means its value will be determined by sender input (e.g. label field) or signer input. (e.g. text field, radio button, checkbox)

 

(2) Just for your reference, I've made a sample package JSON, which includes most of the fields and their type, subtype and binding values (I made comments for each field type):

{
  "documents": [
    {
      "id": "Doc1",
      "approvals": [
        {
          "role": "Signer1",
          "id": "approval1",
          "fields": [

//signing date field
            {
              "binding": "{approval.signed}",
              "id": "uM1x2L9dItw6",
              "page": 0,
              "width": 165,
              "height": 37,
              "subtype": "LABEL",
              "left": 315,
              "top": 216,
              "type": "INPUT"
            },

//signer name
            {
              "binding": "{signer.name}",
              "id": "CSt46WUMyOE8",
              "page": 0,
              "width": 165,
              "height": 37,
              "subtype": "LABEL",
              "left": 315,
              "top": 263,
              "type": "INPUT"
            },

//signer title
            {
              "binding": "{signer.title}",
              "id": "phQawctSUHMS",
              "page": 0,
              "width": 165,
              "height": 37,
              "subtype": "LABEL",
              "left": 315,
              "top": 310,
              "type": "INPUT"
            },

//signer company
            {
              "binding": "{signer.company}",
              "id": "bDpWc85xKPoN",
              "page": 0,
              "width": 165,
              "height": 37,
              "subtype": "LABEL",
              "left": 315,
              "top": 357,
              "type": "INPUT"
            },

//date picker field (you need to contact support in order to turn on this field)
            {
              "binding": null,
              "validation": {
                "pattern": "YYYY-dd-MM"
              },
              "id": "13Cw1UFvcSE1",
              "page": 0,
              "width": 165,
              "height": 37,
              "subtype": "DATEPICKER",
              "left": 315,
              "top": 404,
              "type": "INPUT"
            },

//text field

            {
              "binding": null,
              "id": "SFJrONmoVlAS",
              "page": 0,
              "width": 165,
              "height": 37,
              "subtype": "TEXTFIELD",
              "left": 315,
              "top": 451,
              "type": "INPUT"
            },

//text area field (text field stamps the value in one line, while text area supports text wrapping)
            {
              "binding": null,
              "id": "J6xo2NYTugEI",
              "page": 0,
              "width": 165,
              "height": 37,
              "subtype": "TEXTAREA",
              "left": 315,
              "top": 498,
              "type": "INPUT"
            },

//label field
            {
              "binding": null,
              "id": "johRIQ5HFhw3",
              "page": 0,
              "width": 165,
              "height": 37,
              "subtype": "LABEL",
              "left": 315,
              "top": 636,
              "value": "Some value here",
              "type": "INPUT"
            },

//radio button field
            {
              "binding": null,
              "id": "mQQXkvbrjFcF",
              "validation": {
                "enum": [
                  "RadioGroup1"
                ]
              },
              "page": 0,
              "width": 12,
              "height": 12,
              "subtype": "RADIO",
              "left": 392,
              "top": 567,
              "type": "INPUT"
            },

//checkbox field
            {
              "binding": null,
              "id": "S2DzOWChG5sJ",
              "validation": {
                "group": "CheckboxGroup1"
              },
              "page": 0,
              "width": 12,
              "height": 12,
              "subtype": "CHECKBOX",
              "left": 392,
              "top": 545,
              "type": "INPUT"
            },
//list field
            {
              "binding": null,
              "validation": {
                "enum": [
                  "optionA",
                  "optionB",
                  "optionC"
                ]
              },
              "id": "xAIGgx0he1wS",
              "page": 0,
              "subtype": "LIST",
              "width": 165,
              "height": 37,
              "left": 315,
              "top": 589,
              "type": "INPUT",
              "value": "optionB"
            },

//signature field (If the document is not accept-only, one approval will always have one signature field, which defines its attributes like position and sizing)
            {
              "binding": null,
              "id": "ESrCls7VOboV",
              "page": 0,
              "width": 165,
              "height": 37,
              "subtype": "FULLNAME",
              "left": 187,
              "top": 166,
              "type": "SIGNATURE"
            }
          ]
        }
      ],
      "index": 0,
      "name": "Example Contract"
    }
  ],
  "language": "en",
  "roles": [
    {
      "id": "Signer1",
      "index": 0,
      "type": "SIGNER",
      "signers": [
        {
          "email": "[email protected]",
          "firstName": "John",
          "lastName": "Smith",
          "id": "Signer1"
        }
      ],
      "name": "Signer1"
    }
  ],
  "status": "DRAFT",
  "type": "PACKAGE",
  "timezoneId": "Australia/Sydney",
  "name": "Example Transaction"
}

 

(3)There are two bindings here:

- First is whether the field is a binding field as I explained above

- Another binding is more like "a field is connected to a role". So what I meant in the initial reply is, if a signature (and all its fields) is connected to a role, other signers won't see these field values and the signature until the signer signed. 

 

Duo

Thanks Duo!

1) My assumption is I can use "name" instead of "id". The PDFs I'm using are not new and were providing by our clients. Since the beginning when we started using the sdk they have been setup to use "name" to identify fields.

          "fields": [
            {
              "type": "SIGNATURE",
              "subtype": "FULLNAME",
              "name": "Sign_InsuredSignature_0",
               "binding": null,
              "extract": true
            },
            {
              "type": "INPUT",
              "subtype": "LABEL",
              "name": "DateSigned_0",
              "binding": "{approval.signed}",
              "extract": true
            }

2) We have a new situation, where the signing date field is broken up. Any thoughts on how to handle this?

___ day of, ____ 20___

 

Thanks, Randy

Hi Randy,

 

(1)Yes, field name can also be used to identify a field

(2)I don't think OneSpan Sign has separate fields for signing date, I knew there are already some Enhancement Requests asking for this feature, but it hasn't been delivered yet. As a workaround, it's possible to customize the signing date format as "dd' day of, 'MMMM' 'yyyy" (you need to contact support team to have this set up in your account), see below screenshot:

Duo