Adressing by email and/or phone number

New

• Private sector organizations can now send portal signature jobs without a personal identification number. Just create a PortalSigner using identifiedByEmail(...), identifiedByMobileNumber(…) or identifiedByEmailAndMobileNumber(…, …).
• To retrieve a signature for a given PortalSigner, use the SignerIdentifier used when creating the job and pass it to PortalJobStatusChanged.getSignatureFrom(...).

Tidspunkt for signering tilgjengelig i APIet

APIet returnerer nå tidspunktet for signering, avvisning, kansellering etc. Tilgjengelig på klassen Signature for synkrone og asynkrone oppdrag.

Multisignatar for synkrone oppdrag

Funksjonelt

• Multisignatar for synkrone oppdrag.
  Ved opprettelse av synkrone oppdrag er det nå mulig å spesifisere opp til 10 signatarer (samme grense som for asynkrone oppdrag). Tjenesten vil returnere én redirect-url pr. signatar ved opprettelse som avsender skal videresende brukeren(e) til. Metoden DirectJobResponse#getSingleRedirectUrl() kan brukes for å hente ut redirect-urlen i tilfeller hvor avsender vet at det bare er én signatar. Hvis det er flere signataterer brukes DirectJobResponse#getRedirectUrls() for å hente ut alle. Videre kan man bruke RedirectUrls#getFor(String personalIdentificationNumber) eller RedirectUrls#getAll() for å hente ut henholdsvis redirect-urlen for én spesifikk signatar eller en liste med alle redirect-urler.

  Ved henting av status vil responsen fra tjenesten inneholde én aggregert status for hele signeringsoppdraget. I tillegg kommer én status og 0 eller én URL for å hente XAdES for hver signatar (avhengig om signataren har signert eller ikke). Bruk metoden DirectJobStatusResponse#getSignatures() for å hente ut en liste over alle siganturer, eller DirectJobStatusResponse#getSignatureFrom(String personalIdentificationNumber) for å hente ut signaturen til én spesifikk signatar. Sjekk statusen til en signatar ved å kalle Signature#is(SignerStatus status) før ev. XAdES lastes ned.

Polling på synkrone oppdrag

Funksjonelt

• Polling på synkrone oppdrag.
  Det synkrone API et mot signeringstjenesten er endret med en alternativ måte å hente ned det signerte dokumentet for avsenderen. Utvidelsen gir mulighet til å gjøre generell polling ved å spørre om status på alle synkrone oppdrag for en gitt avsender. På samme måte som i det asynkrone APIet vil klienten tolke alle statuser som returneres (alle åpne synkrone oppdrag) og markere hvilke statuser som er ferdigprosessert før referansen i statusresponsen brukes til å hente det signerte dokumentet.

  For å at et oppdrag skal returneres ved polling, kall retrieveStatusBy(POLLING) på DirectJob.Builder ved opprettelse av oppdraget. Oppdrag med endret status returneres ved kall til DirectClient#getStatusChange().

Varsling

Denne versjonen bryter bakoverkompabilitet ved opprettelse av synkrone og portaloppdrag via API. Se teknisk for mer informasjon.

Funksjonelt

• Varsling av signatarer.
  Oppslagstjenesten slår opp kontaktinformasjon for borgere i Difis Kontakt- og reservasjonsregister for oppdrag som skal signeres i portalen. Dette gjøres for alle nyopprettede portaloppdrag, og vil derfor endre oppførselen for eksisterende virksomheter. Se den funksjonelle dokumentasjonen for mer informasjon om varsling. Endringen er ikke relevant for synkrone signeringsoppdrag.
• Ikke-sensitiv tittel for oppdrag.
  Virksomheter kan spesifisere en ikke-sensitiv tittel for signeringsoppdraget. Denne tittelen kan brukes i kontekster der brukeren ikke er sterkt autentisert, som for eksempel i varsler eller kommunikasjon til saksbehandlere hos virksomheten.

Teknisk

• Bryter bakoverkompabilitet: domeneobjekter for opprettelse av oppdrag.
  Typene Document og Signer som tidligere var felles for synkrone og asynkrone oppdrag har blitt splittet opp for å reflektere at de har ulik funksjonalitet for de to typene oppdrag. Bruk derfor hhv. DirectDocument og DirectSigner for synkrone og PortalDocument og PortalSigner for asynkrone oppdrag.

  PortalSigner#builder har også blitt endret til å kreve enten Notifications eller NotificationUsingLookup. Ved bruk av sistnevnte slår signeringstjenesten opp i Kontakt- og reservasjonsregisteret for å finne varslingsinformasjon for mottakeren. Notifications kan brukes for å overstyre disse. NB: Offentlige virksomheter kan kun overstyre varslingsinformasjonen dersom signataren mottar oppdraget i kraft av en rolle knyttet til sitt arbeid. Private virksomheter har ikke anledning til å bruke Kontakt- og reservasjonsregisteret og må derfor benytte Notifications for å sende med varslingsinformasjon.

Alle endringer er reflektert i dokumentasjonen til versjon 1.1.