Remove requirement to be an authenticated user on the signature page

[vitormattos]

Diagrams

• Tips
  • The six types of relationships in UML class diagrams
  • Sintax
• Setup to edit this file
  • Visual Studio extension
• Diagram

Diagram

classDiagram
    class Token {
        +sendCode(identify, message)
        +validateCode(identify, code)
    }
    class Certificate {
        +sign()
    }
    <<interface>> Token
    <<interface>> Certificate
    class IdentifyMethod {
        +int attempts
        +string code
        +date identified_at_date
        +date last_attempt_date
        +bool default
        +string identifierKey
        +string identifierValue
        +notify(bool isNew)
        +validateToRequestToSign()
        +getState()
    }
    <<Interface>> IdentifyMethod
    class Sms~SignMethod~ 
    class Telegram~SignMethod~
    class Signal~SignMethod~
    class Email~SignMethod~
    class Password~SignMethod~
    class Nextcloud~IdentifyMethod~
    class Mediated~IdentifyMethod~
    Sms --|> Token : implements
    Telegram --|> Token : implements
    Signal --|> Token : implements
    Email --|> Token : implements
    Password --|> Certificate : implements
    class RequestSignature {
        request(File, Users)
        -sendInviteUrl()
    }
    class FileUser {
        list~IdentifyMethod~ identifyMethod
    }
    RequestSignature --> FileUser

    FileUser --|> Nextcloud
    FileUser --|> IdentifyMethod
    FileUser --|> Mediated
    IdentifyMethod --> Sms
    IdentifyMethod --> Telegram
    IdentifyMethod --> Signal
    IdentifyMethod --> Email
    IdentifyMethod --> Password
    IdentifyMethod --> Nextcloud
    IdentifyMethod --> Mediated

Loading

sequenceDiagram
    autonumber
    Note over Requester, LibreSign: Is mandatory: File, Users<br/>Is optional: IdentifyMethod, SignMethod.<br/>Default: IdentifyMethod -> Nextcloud<br/>Default: SignMethod -> Certificate.
    Requester -->> LibreSign: request to sign
    LibreSign -->> Signer: Send sign invite
    Signer -->> LibreSign: Access document
    break when the signer already signed the file
        LibreSign --> Signer: Show already signed
    end
    LibreSign -->> Signer: Identify user
    Signer -->> LibreSign: Send identification code
    break when a bruteforce was identified
        LibreSign --> Signer: Show sign blocked
        LibreSign -->> Requester: Bruteforce identified
    end
    LibreSign -->> Signer: request to sign
    Signer -->> LibreSign: sign document
    LibreSign -->> Requester: Notify that document was signed
    LibreSign -->> Signer: Show signed document

Loading

Ref: https://gist.github.com/vitormattos/4024ac442887671eee9aa6480c7048d7

Tasks

• Fields to add to the file_user table:
  • identify_method: Add identify method #1584
    • nextcloud account, email link, email token, sms token
  • Metadata:
    • ip, geolocation, user agent Collect metadata of signers #1474
• Certificate revocation
  • Consult revocation table before signing when signing with password
• Add time signature to signed document
• Changes in user identification:
  • Remove requirement to be an authenticated user on the signature page
  • Ways to verify the identification method
    • Nextcloud Add identify method #1584
    • Token Add identify method #1584
      • email link: generates session and redirects to subscription page
      • email|sms token: returns the user's email to the partially obfuscated front.
        • Token will be valid for X minutes, X must be a LibreSign configuration with a default value (10 min for example).
        • Question: Is it necessary to ask the user to inform his method of identification by entering the email address or phone number? This is the data that is partially obfuscated.
  • Check the possibility of using more user data to add them to the PFX file.
• Collect user data and save in metadata field of file_user table Collect metadata of signers #1474
• Email with link to signed document
  • Set global LibreSign configuration to enable this feature
  • Define if the user needs to be identified to have access to the signed document link
  • Create LibreSign global configuration to identify if the user who created a process to sign a document will also receive emails with signature reports

[vitormattos]

Mockups: https://excalidraw.com/#room=37417b390e410c871330,Uyh8fUxlUPCz1VAONGdo_A
Description about flow: https://pad.librecode.coop/p/SNXlVEwZrrz5oHIBa6oM

[vitormattos]

Context: We have two possible suggestions of data structure to identify the signers of a document that I detailed at this comment. What you think that is best? Or, did you imagine an other way to send the parameters to identify multiple signers?

My opinion: I prefer the second pattern because sounds more simple to look but maybe will be more complex to implement because we will need to check if all properties of user object match with an identify method. Because this, looking by technical side, the first pattern sounds best.

What you think @enieber, @lhsazevedo ?

////////////////////////////////////////////////////////////////////////////////
// Pattern 1: With an array to identify methods
// Problems: Maybe a complex structure of user object
{
	"users": [
		// With only a signer
		{
			// Most simple with account
			"identify": {
				"account": "signer1"
			}
		}
	]
}

{
	"users": [
		// With only a signer
		{
			// Most simple with email
			"identify": {
				"email": "a@b.coop"
			}
		}
	]
}

{
	"users": [
		// With only a signer
		{
			// Using display name and multiple identify factors
			"displayName": "John Doe",
			"identify": {
				"account": "signer1",
				"email": "a@b.coop"
			}
		}
	]
}

{
	"users": [
		// With multiple signers
		{
			// Most simple with account
			"identify": {
				"account": "signer1"
			}
		},
		{
			// Most simple with email
			"identify": {
				"email": "a@b.coop"
			}
		},
	]
}

////////////////////////////////////////////////////////////////////////////////
// Pattern 2: Withount an array to identify methods
// Problems: Can't define more details about user because all properties,
//           except the displayName will be identify methods
{
	"users": [
		{
			// Using display name and multiple identify factors
			"displayName": "John Doe",
			"account": "signer1",
			"email": "a@b.coop"
		}
	]
}

[vitormattos]

• Add signers
  • Get allowed identification methods from backend.
    • Check if is possible to use initial state
  • Hide signers list when click at add signer
  • List allowed identification methods
    • Create a component by identification method
      • Flag mandatory methods
      • Account
        • Need to list accounts when typing. Check file_sharing app when share a file with an account.
      • Add button to delete an identification method
        • Can't delete a factor that is mandatory
  • Implement button to add factor
    • Only add a factor that aren't added
  • Save identification methods
    • Validate response to check if have an error and implement the logic to don't close the add signers screen when have an error reported by API.
    • Reload signers list when save the current signer.

[vitormattos]

Resolved at newest release