Systembeskrivelse for eksterne aktører Med milepæl 3 gir Kartverket neste innblikk i den kommende løsningen for elektronisk tinglysing. Milepæl 3 gir eksterne aktører mulighet til å få innsikt i grensesnitt og anvendt teknologi for interaksjon med det nye grunnboksystemet. Løsningen for elektronisk tinglysing bygger videre på de konsepter og teknologier som er anvendt for Ny grunnbok, og tilbyr et nytt Web Service basert api for elektronisk innsending av dokumenter til tinglysing. Grensesnittet tilbyr tjenester for validering av dokumenter før innsending, tjenester for innsending til tinglysing samt tjenester for uthenting av tinglysingsresultat. I tillegg tilbys den funksjonalitet som ble introdusert med Ny grunnbok. Konsepter Melding Den minste enhet som kan sendes til tinglysing er en melding inneholdende ett eller flere dokumenter, hvert bestående av en eller flere rettsstiftelser. Alle dokumenter i en melding behandles som en transaksjonell enhet, slik at alle dokumenter blir enten avvist, nektet eller tinglyst. Alle dokumenter i en melding får samme prioritet, men behandles i en gitt rekkefølge som må eksplisitt angis av innsender i et følgebrev ved innsending. Dokument Den enheten som tinglyses kalles et dokument, og består av en eller flere rettsstiftelser som tinglyses i den rekkefølge de er oppført i dokumentet. Før et dokument kan legges i en melding og sendes til tinglysing må det pakkes i en digital struktur og signeres digitalt av de personer som måtte være nødvendig for å få dokumentet tinglyst. Alle signaturene for et dokument gjelder hele dokumentets innhold, det vil si at alle signatarene må signere på eksakt det samme innholdet. Det er ikke mulig å signere på enkeltelementer i dokumentet. Når et dokument har blitt signert av alle parter må innsender sørge for å kombinere signaturene samt forsegle strukturen. Da er dokumentet klart til å legges i en melding sammen med eventuelle andre signerte dokumenter. Dokumenter som skal inngå i en melding kan opprettes og signeres uavhengig av hverandre. Signeringsteknologien sikrer integriteten til innholdet, det vil ikke være mulig å endre på innholdet av et signert dokument. Signeringsløsningen vil sjekke om noen av sertifikatene som ble brukt til å signere med har blitt tilbakekalt eller har utløpt, slik at kun gyldige sertifikater vil bli akseptert. Følgebrev Før innsending må innsender lage et følgebrev som ved hjelp av interne dokumentreferanser i meldingen lister opp alle dokumenter som meldingen inneholder. Følgebrevet angir dermed entydig hvilke dokumenter som inngår i meldingen uten at dokumentene selv må være en del av følgebrevet. Følgebrevet legges i en digital struktur som signeres av innsender. Det signerte følgebrevet og de signerte dokumentene legges i en åpen meldingsstruktur som sendes til tinglysing. Rekkefølgen på dokumentene i meldingen må være den samme som angitt i følgebrevet.
Vedlegg Støtte for vedlegg til dokumenter er ikke planlagt for første versjon av systemet. Det innebærer at dokumenter som krever vedlegg vil bli avvist ved elektronisk innsending og vil måtte sendes inn på papir. Et eksempel kan være dokumenter der noen av de berørte parter er mindreårige. Innsendingsgrensesnitt Milepæl 3 inneholder en prototype på signeringsløsning, basert på SEID-SDO med bruk av BankID XML og XSL for visning av dokumenter til signering for sluttbruker. Innsendingsapi for tinglysing støtter validering og tinglysing av signerte og usignerte meldinger som inneholder instruksjoner om dokumenter som skal tinglyses. Grensesnittet er tilpasset signeringsløsningen på en slik måte at datastrukturen som representerer dokumentene, og som sendes inn i tjenestene, er den samme som brukes som grunnlag for visning med XSL med BankID eller med andre eid-leverandører som støtter BIDXML. Som kontaktpunkt for BankID henvises til https://www.bankid.no/for-partnere/ Tjenester For milepæl 3 er det implementert fire funksjoner for innsending. Disse kan brukes uavhengig av grunnbokens øvrige tjenester, og uavhengig av hverandre med unntak av at man må allokere en innsendingid for å kunne sende en melding til tinglysing. Man bruker den samme innsendingid for å hente ut behandlingsstatus på en melding som er sendt til tinglysing. Signerte data vil kunne brukes i tjenestene for å validere og å sende melding til tinglysing i produksjon og i test. For signerte meldinger i test kommuniserer grunnboksystemet med BankID i test, og aksepterer meldinger signert av sertifikater utstedt fra BankID test CA. Følgende tjenester tilbys: allokerinnsendingid Tjenesten brukes for å finne en gyldig, ikke-brukt og unik id som kan refereres til i innsendingsapiet. Denne verdien skal settes når man skal sende en melding til tinglysing slik at man kan referere til den senere, for eksempel gjennom å hente behandlingsstatus for meldingen. Denne id er også med til å sikre at en gitt melding med en gitt id vil behandles kun en gang. Ved kommunikasjonsfeil eller andre systemfeil hos innsender eller under mottaket av meldingen, kan innsender gjenta kallet med samme innsendingid inntil kallet går igjennom. Innholdet i meldingen vil kun bli tinglyst en gang. Hvis innsendingid har blitt mottatt av systemet tidligere vil man få en feilmelding. validermelding Tjenesten kan kalles for å validere en signert eller en usignert melding, både i test og i produksjon. Valideringstjenesten gir ingen garanti for at dokumenter som validerer uten feil vil kunne tinglyses. Formålet med tjenesten er å forsøke å finne opplagte mangler i dokumenter før de sendes til signering, eller gjøre oppmerksom på eventuelle forhold på valideringstidspunktet som kan hindre tinglysing. Tjenesten vil for signerte meldinger slå opp data samt validere mot eid-leverandørers testsystemer.
tinglysmelding Etter at man har allokert en gyldig innsendingid, kan en signert eller usignert melding sendes til tinglysing. Signerte meldinger kan sendes til tinglysing både i test og i produksjon, mens usignerte meldinger kan sendes til tinglysing kun i test. I forkant kan det være nyttig å ha testet at meldingen validerer. Det vil kunne være de samme feilene som propageres fra tinglysmelding som fra validermelding, gitt at valideringen feiler. Tjenesten vil i produksjon slå opp data samt validere mot eid-leverandørers produksjonssystemer. Dette har en kostnad, men det er ikke avklart hvem denne kostnaden vil belastes. findbehandlingsstatus Etter at en melding er mottatt av systemet kan man hente oppdatert behandlingsstatus for den innsendte meldingen. Sekvensdiagram Det tilbys eksempelklienter for Java og.net som viser eksempler på hvordan innsendingsapiet kan brukes for validering og tinglysing av dokumenter.
Forsendelse Dokumenter som ønskes tinglyst som en enhet samles som en signert eller en usignert melding i en forsendelse. Meldingen inneholder ett eller flere dokumenter, samt et følgebrev som refererer til de individuelle dokumentene, og dermed også bekrefter hvor mange dokumenter forsendelsen inneholder og hvilken rekkefølge disse har. Følgebrevet inneholder også innsenders identifikasjonsnummer, og det valideres at innsender er en eksisterende person eller organisasjon. Innsender må signere på følgebrevet med sitt brukerstedssertifikat. For signerte meldinger er det i tillegg et krav at digest og digestalgoritme er utfylt i referansen til hvert dokument som ønskes tinglyst. Signert følgebrev uten digest eller algoritme vil bli avvist. For usignerte meldinger valideres det ikke på digest. Dokumenter og følgebrev i en signert melding må base64 encodes. Den oppgitte digesten må være en av de digestene som er oppgitt i SDO for den signerte meldingen. Hvis det er forskjellige digester som har vært benyttet på signaturene i SDO så er det nok at den matcher en av dem som har blitt benyttet. Digesten beregnes på hele BIDXML strukturen, og fungerer således på samme måte som digesten i SEID-SDO dokumentene. Gyldige digest-algoritmer er SHA1 og SHA256. Forsendelsen inneholder også en allokert innsendingid, samt en innsenders referanse som kan brukes til innsenders formål. Videre kan den inneholde ikke-digitale signaturer for usignerte meldinger. Disse signaturene kan benyttes for å på forhånd validere at de som er tiltenkt å være signatarer for et gitt dokument er de som faktisk er påkrevd å signere, samt for å sende usignerte meldinger til tinglysing i test. Innsendingsgrensesnittet er utformet med henblikk på at dokumenter skal kunne opprettes og signeres uavhengig av grunnboksystemet, dersom innsender har tilstrekkelig informasjon. Blant annet må innsender ha informasjon om koder som skal anvendes i dokumentene som skal tinglyses. Informasjon om koder er statisk og vil kunne hentes på forhånd. Innsendte koder som ikke kan oversettes til koder systemet kjenner igjen vil forårsake systemfeil.
Behandlingsstatus Tjenestene for validering og tinglysing returnerer en behandlingsstatus. For meldinger som er sendt til tinglysing og som er mottatt av systemet, kan oppdatert behandlingsstatus hentes gjennom tjenesten findbehandlingsstatus. Hvis dokumentene i meldingen er avvist vil behandlingsstatus inneholde begrunnelsene for avvisningen i form av strukturert informasjon og lesbare tekster. Dersom dokumentene i meldingen er blitt registrert i grunnboken inneholder behandlingsstatus blant annet informasjon om registreringstidspunkt (prioritet), samt tildelte dokumentnummer og rettsstiftelsesnummer. Disse er angitt med en kobling til innsenders oppgitte referanser for hhv. dokumentene og rettsstiftelsene. Når dokumentene i meldingen er tinglyst gjøres det også tilgjengelig et sett av signerte grunnboksutskrifter for de registerenheter som er berørte av denne tinglysingen. Feilhåndtering For forventede feil som systemet håndterer, f.eks. valideringsfeil, returneres begrunnelsene i form av informasjon i behandlingsstatus, som beskrevet over. Ved uventede feil, eller dersom meldingen ikke er lesbar, vil slike feil propageres som en SOAPFault med en SystemException som underliggende årsak. I slike tilfeller må avleverende system forsøke å rette feilen i sitt fagsystem før meldingen sendes på nytt, eller vente til eventuelle feil er rettet i mottakende system. Et eksempel på en slik feil kan være innsendt XML som ikke er i henhold til skjema.
Kontekstinformasjon I forbindelse med signering av dokumenter er det krav til å vise tilleggsinformasjon (kontekstinformasjon) for sluttbruker, slik som navn på personer, for at sluttbruker skal få bedre forståelse av hva det signeres på. Ved innsending må alltid fullstendig identifikator for hvert dataelement sendes inn, selv om denne ikke nødvendigvis er vist for sluttbruker. Også kontekstinformasjon vist for sluttbruker må sendes inn, selv om systemet i utgangspunktet ikke har behov for denne. Det stilles krav til validering av innsendt kontekstinformasjon. Eksempelvis er det krav om at navn og identifikasjonsnummer på personer skal valideres mot data fra folkeregisteret, mens kodeverdi og navn på koder skal valideres mot systemets egne data. Systemet avviser en melding dersom validering av kontekstinformasjon feiler. Prosessflyt Systemet implementerer en asynkron prosessflyt, slik at tinglysingskallet kun sikrer at systemet har mottatt meldingen. Videre behandling av meldingen skjer asynkront. Innsendingsapiet har tjenesten findbehandlingsstatus som innsender kan kalle for å følge med på meldingens behandlingsstatus. Når tjenesten for å tinglyse en melding har returnert uten feil, garanteres det at meldingen er mottatt av systemet og at et påfølgende kall som henter behandlingsstatus vil returnere en ikke-tom respons. Funksjonalitet og begrensninger I Milepæl 3 er alle 8 typer rettsstiftelser som skal kunne sendes inn av eksterne aktører i første versjon av systemet tilgjengelig for elektronisk innsending: Eierskifte matrikkelenhet Overdragelse av festerett Eierskifte borettslagsandel Pant Annen heftelse Sletting Tvangsforretning Anmerkning på person Dokumentasjon av rettstypene finnes i UML-modellen for innsending. Implementasjonen av hver rettstype er ikke komplett, det vil si at det kan være valideringsregler og annen forretningslogikk som vil komme på plass senere. Det samme gjelder valideringslogikk rundt selve forsendelsen. Enkelte typer rettsstiftelser skal kun kunne sendes inn av en spesifikk aktør, slik som Statens Innkrevingssentral, kontroll av dette er ikke implementert i milepæl 3. Innsendingsgrensesnittet krever at XML-delen tilhørende BIDXML kan valideres mot XSD for namespacet for innsendingsskjemaet. Dette må oppgis på standardisert vis med namespacehenvisning i XML-dokumentet. Det kreves også at XSL-delen tilhørende BIDXML kan valideres mot godkjente versjoner av XSL transformasjonen. Innpakket XSL må således være binært identisk med en versjon som er publisert av Kartverket. Milepæl 3 eksponerer det nye apiet som namespace internal eller vi. I en senere versjon vil apiet bli eksponert som v2. internal apiet inneholder også tilsvarende tjenester og modell som v1, med noen justeringer i namespace-definisjonene for tjenestene og noen endringer i domenemodellen. Forbehold Milepæl 3 representerer et system under utvikling der de ulike deler av systemet vil være gjenstand for forandringer. Løsningen kan ha mangelfull implementasjon samt inneholde feil.