...
...
...
...
...
Innehållsförteckning |
---|
Revisionshistorik
Version | Datum | Författare | Kommentar |
---|---|---|---|
0.9 | 2020-12-01 | Marco de Luca |
|
0.9 (2022) | 2022-02-14 | Marco de Luca | Revidering 2022
|
1.0 (2022) | 2022-02-28 | Marco de Luca | Beslutad version för Tjänsten Säker digital kommunikation. |
1. |
...
Syfte: SDK är en säker transportinfrastruktur för asynkron punkt-till-punkt(meddelande levereras direkt till mottagarens Accesspunkt) arkitektur som bygger på DIGGs Transportinfrastruktur för eDelivery (baserad på CEF eDelivery).
För att etablera SDK-förmåga inom en användarorganisation behöver IT-stöd anpassas och en eller flera klienter/verksamhetssystem behöver anslutas.
Accesspunkt:
...
1 (2022) | 2023-09-12 | Marco de Luca | Uppdatering för att tydliggöra att komponenter bör kravställas att vara “öppna” för att minska risk för leverantörs inlåsning. |
1.2 (2023) | 2023-10-25 | Marco de Luca | Förtydligande att SDK Adressbok används för att söka fram och validera avsändare/mottagare. Uppdaterad information under sektion “Leverantörsmarknad” |
1. Inledning
Syfte: SDK är en säker transportinfrastruktur för asynkron punkt-till-punkt (meddelande levereras direkt till mottagarens Accesspunkt) arkitektur som bygger på DIGGs Transportinfrastruktur för eDelivery (baserad på CEF eDelivery).
För att etablera SDK-förmåga inom en användarorganisation behöver IT-stöd anpassas och en eller flera klienter/verksamhetssystem behöver anslutas.
Accesspunkt(AP):
En Accesspunkt är en standardiserad mjukvara som anpassas enligt DIGGs tekniska specifikationer.
“AP-operatör“ är den part som tillhandahåller Accesspunkt till en eller flera användarorganisation i enlighet med DIGGs regelverk och avtal (En Accesspunkt kan delas).
En AP-operatör kan vara användarorganisationen själv eller anlita en extern leverantör.
Meddelandetjänst:
En integrationskomponent för att En Accesspunkt ska ha ett öppet tillgängligt API för att kunna integrera med olika Meddelandetjänster.
Meddelandetjänst(MT):
En integrationskomponent för att hantera meddelandeflöden mellan accesspunkt och meddelandeklienter/verksamhetssystem. En användarorganisation kan ha en(1) meddelandetjänst.
Dekrypterar, krypterar, signerar och validerar signatur på SDK meddelanden.
Validera och kvittera meddelanden (meddelande mottaget).
Validerar giltig avsändare och mottagare mot SDK Adressbok.
Ansvarar för att leverera meddelandet internt inom användarorganisationen.
En meddelandetjänst ska ha ett öppet tillgängligt API för att kunna integrera med olika Accesspunkter och Meddelandeklienter.
Meddelandeklient/Verksamhetssystem (MK):
Representerar ett verksamhetssystem där användaren finns.
Meddelandeklienten behöver anpassas anpassas för att kunna hantera SDK-meddelanden och kvittenser
...
.
Meddelandeklienten ska ha ett öppet tillgängligt API för att kunna integrera med olika Meddelandetjänster.
Söker mottagare i SDK Adressbok
Mål: Stödja en användarorganisation som skall etablera SDK-förmåga. Dokumentet lyfter fram områden som behöver utredas och vägval som behöver göras.
...
Läsaren rekommenderas även att besöka SDKs publiceringsplats https://inera.atlassian.net/wiki/spaces/OISDK/pages/2644705403
Ref | Dokument-id | Dokument länk |
---|---|---|
R1 | Specifikation av validering, felhantering och kvittens | |
R2 | SDK Innehållsspecifikation - Meddelande | |
R4 | SDKs Testinstruktioner för anslutningstester | |
R5 | Säker digital kommunikation SAD | |
R6 | Regelverk för anslutning till Säker digital kommunikation - Informationssäkerhet och IT-säkerhetsbilaga | |
R9 | SLA Tillgänglighet | |
R10 | SDK Adressbok Användarhandledning Administratör | |
R11 | SDK Adressbok | Informationsmodell, kodverk och Sök-API. |
R12 | Meddelandespecifikation: Meddelandekvittens | DIGGs informationspaket kan erhållas genom en förfrågan till DIGG via info@digg.se |
R14 | Transportmodell - Utökad Bas | DIGGs informationspaket kan erhållas genom en förfrågan till DIGG via info@digg.se |
R15 | Transportprofil AS4 | DIGGs informationspaket kan erhållas genom en förfrågan till DIGG via info@digg.se |
R16 | PKI för Accesspunkter Tjänstebeskrivning | DIGGs informationspaket kan erhållas genom en förfrågan till DIGG via info@digg.se |
R17 | Accesspunktsoperatör - Gemensamma Regler och Rutiner | DIGGs informationspaket kan erhållas genom en förfrågan till DIGG via info@digg.se |
R18 | Kuverteringsprofil XHE | DIGGs informationspaket kan erhållas genom en förfrågan till DIGG via info@digg.se |
R19 | Certifikatspublicering - REST-bindning till SMP | DIGGs informationspaket kan erhållas genom en förfrågan till DIGG via info@digg.se |
R20 | Plattform - Informationssäkerhet och tillitsmodell | DIGGs informationspaket kan erhållas genom en förfrågan till DIGG via info@digg.se |
2. Sourcingstrategi SDK förmåga (Vägval för etablering)
...
Vid tillämpning av regelverk och specifikationer finns det frihet hur krav skall implementeras. Det finns en hel del vägval som anslutande användarorganisationer behöver överväga.
Vägval | |||
---|---|---|---|
Accesspunkt vi AP-operatör | Meddelandetjänst | Meddelandeklient | |
Användarorganisation |
|
|
|
Alternativ som bör övervägas:
Alternativ | Kommentar |
---|---|
Ta fram själv/Egen utveckling/Anpassa befintliga lösningar
|
|
Anskaffa komponenter
|
|
Upphandlingsstöd saknas
|
Gå samman/gör tillsammans med andra
Organisationer kan gå samman och etablera Acesspunkt och SDK-Komponenter.
|
Gå samman/gör tillsammans med andra
|
| |
Köpa som tjänst
|
|
3. Anskaffa helhetslösning eller anskaffa/utveckla olika delar
Avsnittet beskriver vilka vägval som kan bli aktuella för en användarorganisation. SDKs referensmodell delar upp de förmågor som behöver etableras i tre block. Dessa “block” bör ses, och kunna hanteras, som fristående komponenter.
Block1: Accesspunkt och konnecktor
Oavsett anskaffningsstrategi är Meddelandetjänst/meddelandeväxel en strategisk komponent då den är central för en användarorganisations meddelandeutbyte mellan en/flera meddelandeklient/verksamhetssystem och accesspunkt för vidare distribution inom SDK-federationen.
...
Tips |
---|
Viktiga vägval: Fördelar
Nackdelar
|
3.2 Anskaffa eller utveckla olika delar själv
...
Rekommendation: Även om en helhetslösning anskaffas är det viktigt att säkerställa att komponenter levereras med öppna APIer som möjliggör att komponenter kan bytas ut eller utökas. T.ex. för komponenter levereras med ett öppet tillgängligt API som möjliggör byte av Accesspunkt, Meddelandetjänst och Meddelandeklienter. |
3.2 Anskaffa eller utveckla olika delar själv
Att etablera SDK-komponenter separat passar sannolikt organisationer som långsiktigt vill integrera med flera meddelandeklienter/verksamhetssystem.
...
Tips |
---|
Rekommendation:
Fördelar
Fördelar
Nackdelar
|
...
Inom SDK-federationen fördelas ansvar enligt följande.
...
Ansvarig för eDelivery transportinfrastruktur | I Sverige ansvarar Myndigheten för digital förvaltning, DIGG, för eDelivery transportinfrastruktur. |
SDK-federationsägare | SDK-federationsägare ansvarar för federationen gentemot ansvarig för eDelivery transportinfrastruktur. SDK-federationsägare kan utse SDK-federationsoperatör. För närvarande är Inera både SDK-federationsägare- och operatör. |
SDK-federationsoperatör | SDK-federationsoperatör är den organisation som förvaltar SDK och tillhandahåller SDKs gemensamma komponenter, miljöer och regelverk. För närvarande är Inera både SDK-federationsägare- och operatör. |
Accesspunktsoperatör (AP-operatör) | Accesspunktsoperatör avser den roll som ansluter användarorganisationen till eDelivery transportinfrastruktur via en accesspunkt. En AP-operatör kan hantera många användarorganisationer. |
Accesspunkt | Accesspunkten utgör respektive användarorganisations anslutningspunkt till eDelivery transportinfrastruktur. Accesspunkten är den anslutningspunkt som en användarorganisation använder för att överföra meddelanden till andra användarorganisationer i SDK via eDelivery transportinfrastruktur. En Accesspunkt kan delas av användarorganisationer. |
Användarorganisation | Användarorganisation avser den organisation som har anslutit eller har för avsikt att ansluta till SDK i syfte att överföra digitala meddelanden till andra användarorganisationer. Användarorganisation i SDK motsvarar deltagare i eDelivery transportinfrastruktur. |
4.1 Informationsklassning
...
Hanteras av AP-operatör - Accesspunkt:
Transportkryptering (TLSmTLS) kan även implementeras i skalskydd
Tillförlitlig källa för metadata och teknisk adressering. Signering av metadata i Metadatatjänst (SMP) och Certifikatspubliceringstjänst (CertPub, del av SMP)
AS4 meddelandekryptering (WS-Security AP till AP)
...
Kryptering och signering (Kryptering och signering av nyttolast, SDK meddelandet. Signering av kvittensmeddelande)
Meddelandet krypteras och signeras innan det lämnas till Accesspunkt för meddelandeöverföring.
Behörighetshantering mellan Accesspunkt och Meddelandeklienter.
Läs mer om säkerhet i SDK SAD R5).
...
S: Small
M: Medium
L: Large
Komponent | Ansvar | Beskrivning | Omfatt-ning |
---|---|---|---|
Meddelandeklient/Verksamhetssystem | Användar-organisation | Meddelandeklienten eller verksamhetssystem är den komponent där verksamhetsprocessen och användarna finns. En användarorganisation |
kan ha många verksamhetssystem/meddelandeklienter. |
En funktionsadress slutdestination är Meddelandeklienten. Meddelandeklient/verksamhetssystem ansvarar för permanent lagring av information samt integrerar med SDK-federationen via |
dess Meddelandetjänst (MT). Meddelandeklient behöver kunna söka I SDK Adressbok. Komponenten bör ha ett öppet tillgängligt API som möjliggör integration med olika Meddelandetjänster. | L | ||
Meddelandetjänst/ meddelandeväxel | Användar-organisation | Meddelandetjänst/Meddelandeväxel, hanterar integration mellan accesspunkt och meddelandeklienter. En användarorganisation har normalt en meddelandetjänst/meddelandeväxel men kan ha flera. Komponenten ansvarar också för kryptering, dekryptering, signering och validering av signatur samt validering och kvittering av meddelanden. Validerar avsändare mottagare mot SDK Adressbok. Komponenten bör ha ett öppet tillgängligt API som möjliggör integration med olika Accesspunkter och Meddelandeklienter. | L |
Accesspunkt | AP-operatör | En användarorganisation har normalt en (1st) accesspunkt som hanterar alla dess meddelandeutbyten inom SDK-federationen. En Accesspunkt måste tillhandahållas av en rollen AP-operatör som regleras av DIGG. En användarorganisation kan vara AP-operatör. |
S
Komponenten bör ha ett öppet tillgängligt API som möjliggör integration med olika Meddelandetjänster. | S | ||
Accesspunkt validering | AP-operatör | En AP-operatörs Accesspunkt skall konfigureras enligt DIGGs ansvisningar och valideringsprocess | M |
Adressbok (gemensam komponent) | SDK-federationsoperatör | ||
Adressbok (Innehåll) | Användar-organisation | Behörig administratör underhåller funktionsadresser. Funktionsadressens tekniska adress behöver samordnas med meddelandetjänsten/meddelandeväxelns “routing”- funktion. Denna hanterar leverans av meddelande till funktionsadressens meddelandeklient/verksamhetssystem. Funktionsadresser bör också kodas(kodverk) för att öka sökbarhet och möjliggöra strukturerad sökning av funktionsadresser. Se avsnitt SDK Adressbok för mer information. | M |
SMP (gemensam Komponent) | DIGG Federationsoperatör (DIGG) | ||
SMP/CertPub (AP metadata) | AP-operatör | Behörig användare underhåller metadata(Certifikat, URL till AP etc) för användarorganisationens AP. Hanteras av AP-operatör via DIGGs |
anvisning. | S | ||
O2O-certifikat
| Användar-organisation | Certifikat för O2O-kryptering (Organisation till organisation) anskaffas från godkända certifikatsutgivare (Se Regelverk för anslutning R6.) | M |
Uppfyllande av informationssäkerhetskrav och SLA | Användar-organisation (via självdeklaration) | Krav på användarorganisationen gällande informationssäkerhet och it-säkerhet.
| M |
Tips |
---|
Rekommendation:
|
...
Tabellen sammanställer områden som kan underlätta anslutande parts förstudie för införande
Meddelandeklient | Meddelandetjänst | Accesspunkt | |
---|---|---|---|
Informationslagring
| |||
Informationslagring
| |||
Multifaktorsautentisering av personal | |||
Behörighetsstyrning av personal | |||
Autentisering integration | |||
Transportkryptering (TLS) | |||
Meddelandekryptering | Meddelande | AS4 | |
Standardiserad mjukvara tillgänglig | Anpassning enligt DIGG krav krävs | ||
Validering och kvittering av meddelande | |||
Integrerar direkt eller indirekt mot mot SDK Adressbok | |||
Loggning | |||
Routing
| |||
Koppling till Adressbok | |||
Koppling till SMP/CertPub |
7.1 Meddelandeklient - Verksamhetssystem
...
Alla funktionsadresser som skapas i SDK Adressbok skall i slutändan levereras till en meddelandeklient eller verksamhetssystem. Hur många Meddelandeklienter eller verksamhetssystem som skall anslutas till SDK flöden avgöras av det lokala IT-landskapets utformning.
Meddelandeklienten ska också ha ett behörighetssystem som säkerställer att endast behörig användare har tillgång till information som förmedlas via SDK-federationen.
Meddelandeklienten/verksamhetssystemet behöver kunna hantera två meddelandetyper (dokumenttyper, xml-meddelanden)
...
Sammanfattning:
Tips |
---|
Rekommendation:
|
...
Tips |
---|
Rekommendation Några områden som man bör titta närmare på är att meddelandeklienten eller verksamhetssystemet kan:
|
...
Användarorganisationen behöver ta fram etablera en komponent som kallas Meddelandetjänst/Meddelandeväxel (MT). MT skulle kunna beskrivas som en integrationsmotor som löpande hämtar och lämnar meddelanden mellan accesspunkten och meddelandeklienter/verksamhetssystem (via dess interna t.ex. APIer: SOAP eller REST).
...
Meddelandetjänsten ansvarar för att
Kryptera, dekryptera, signera och validera signatur av meddelanden
Validera SDK meddelanden. Dvs kontrollera att meddelandet följer schema och regelverk.
Kontrollera att funktionsadressen är korrekt och är aktiv.
Skapa ett kvitteringsmeddelande (inkl felmeddelanden om en funktionsadress har angivits som inte finns aktiv)
Ansvarar för att "routa" meddelanden till det verkssamhetssystem verksamhetssystemen (MeddelandeklientMeddelandeklienter) som ansvarar för funktionsadressen. Man bör ta höjd för att kunna hantera flera meddelandeklienter.
Svarstidsbevaka skickande meddelanden (dvs att ett skickat meddelande kvitteras av mottagaren. En kvittering innebär att meddelandet är utlämnat och har nått mottagaren)
Kommunicera meddelandestatus till Meddelandeklient (Verksamhetssystem)
Integrationsgränsnitt
Öppet integrationsgränssnitt (API)för att integrera med olika meddelandeklienter och accesspunkter
Ett säkerhetskoncept för att säkra organisationens “inre säkerhet“.
Transportkryptering
Autentisering av systemkomponenter
Behörighetskontroll
Certifikat för signering och kryptering av meddelanden
Externa komponenter
DNS för dynamisk inhämtning av metadata från SMP
CertPub (SMP) register med användarorganisationers publika nycklar (kryptering, validering av signatur).
SDK Adressbok för adressuppslag
...
Lucidchart | ||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Bilden illustrerar på en övergripande nivå förmågor som meddelandetjänsten utför i SDK meddelandeflöde. Flödet kan appliceras för både inkommande och utgående meddelanden.
Meddelandetjänsten utgör en meddelandeväxel som transporterar meddelanden mellan meddelandeklienter (t.ex. verksamhetssystem) och användarorganisationens accesspunkt. Nedanstående tabell lista övergripande funktioner/förmågor som komponenten behöver stödja.
Se SDKs Testinstruktioner för anslutningstester (ref R4) för testfall som verifieras vid anlutning till SDK-federation.
Övergripande |
---|
Vilket stöd tillhandahållas av SDK federationen.(Testbädd - QA, Öppen Testmiljö för tjänsteleverantörer)
Adapter (konnektor)
En adapter används för att uppnå lös koppling(integration) mellan Accesspunkt och Meddelandetjänst/meddelandeväxel. Denna komponent är inte standardiserat av EU/CEF (byggblock eDelivery).
Komponenten kan även ansvara för innehållsvalidering (Schema, Scheamtron)
API eller meddelandekö
Ingår endast i Meddelandetjänstens ansvar i de fall användarorganisationen också agerar AP-operatör. Detta kan vara vanligt förekommande i t.ex. helhetslösningar.
Kan i en helhetslösning uppfylla ansvar med följsamhet till och hantering av de krav och regelverk som gäller för AP-operatörer inom SDK-federationen. D.v.s. hanterar t.ex. incidenthantering vid fel.funktion/förmågor | Vilket stöd tillhandahållas av SDK federationen.(Testbädd - QA, Öppen Testmiljö för tjänsteleverantörer) |
---|---|
Adapter (Connector) En adapter används för att uppnå koppling (integration) mellan Accesspunkt och Meddelandetjänst som inte är produktspecifik. Denna komponent är inte standardiserad av CEF |
. Adaptern bör ha ett öppet tillgängligt API för att möjliggöra integration av olika leverantörers lösningar.
| Verifieras vid DIGGs anslutningstester för AP-operatör. Verifieras även indirekt via SDK Testbädd (QA) genom att meddelanden skickas, valideras och kvitteras med t.ex. Testklient. Rekommenderade specifikationer:
|
Hämta(lämna) Komponent som löpande hämtar/lämnar meddelanden från accesspunkten. Det kan vara en meddelandekö, pollning eller hämtning baserat på notifiering. Funktionalitet:
| Verifieras i SDK anslutningstester indirekt genom att meddelanden skickas, valideras och kvitteras. Rekommenderade specifikationer:
|
Dekryptera, Validera Komponenten dekrypterar, validerar signatur, validerar meddelandets struktur dvs kontrollera att meddelandet följer schema och regelverk(schematron).
| Verifieras genom att meddelanden skickas, valideras och kvitteras med Testklient. Rekommenderade specifikationer:
|
Status Komponenten skapar ett sk kvitteringsmeddelande eller ett felmeddelande.
Persistens/lagring av meddelandet och meddelandets status under pågående transaktion.
| Verifieras genom att meddelanden skickas, valideras och kvitteras med Testklient. Rekommenderade specifikationer:
|
Vägval/”routing”
Vägval/routing funktion bör stödja olika verksamhetssystem/Meddelandeklienter. | Verifieras EJ av Testklient (lokal hantering) |
Skicka
| Verifieras indirekt genom att Testklient skickar ett kvitteringsmeddelande. Rekommenderade specifikationer:
|
| Verifieras EJ av Testklient (lokal hantering) Krav specificerade i Inre säkerhet i dokumentet: IT-säkerhetsbilaga till regelverk för anslutning till Säker digital kommunikation - Informationssäkerhet (Se ref R6). |
Komponent | Beskrivning |
---|---|
Katalog | Katalogfunktion som innehåller funktioners tekniska adress etc. En funktionsadress behöver en teknisk adress för att kunna levereras till rätt meddelandeklient. I de fall det endast finns en Meddelandeklient kan denna komponent vara överflödig. |
Meddelandestatus | Persistens/lagring av meddelandet under pågående transaktion.
|
Dekrypter, Validera | Applikation som validerar meddelanden.
|
Vägval | Komponenten hämtar teknisk adress till den Meddelandeapplikation/verksamhetssystem som hanterar funktionsadress.
|
Router/Skicka | Komponenten levererar meddelandet till Meddelandeklient/verksamhetssystem.
|
Adapter/konnektor | Anpassningskomponent mellan meddelandetjänst och komponenter som Accesspunkt eller Meddelandeklient/verksamhetssystem.
|
Sammanfattning:
Tips |
---|
Rekommendation: Meddelandetjänst/meddelandeväxel är en komponent där utveckling/anpassning är nödvändig.
|
7.4. Accesspunkt (AP)
Accesspunkten är en integrationskomponent som är baserad på en standardiserad mjukvara. Accesspunkten består av applikationsserver, applikation och databas. Komponenten skall installeras och konfigureras enligt DIGGs anvisningar för att fungera i SDK-federationen (Se R15, R16, R17).
...
Tips |
---|
Rekommendation:
|
8. SDK Adressbok
SDK Adressbok är ett gemensamt adressregister för information om SDK-anslutna användarorganisationer och funktioner inom dessa. SDK Adressbok är en komponent i SDK-federatioen.
...
Tips |
---|
Rekommendation: Lokal läskopia: Fördelar:
Nackdelar:
|
9. Leverantörsmarknad
...
|
9. Leverantörsmarknad
Idag finns inget specifikt ramavtal för SDK-komponenter. Adda inköpscentral kommer framöver att kunna erbjuda stöd i form av ett dynamiskt inköpssystem för Säker digital kommunikation. Mer information om det stöd som erbjuds via Adda finns att läsa här: https://www.adda.se/upphandling-och-ramavtal/planerade-och-pagaende-upphandlingar/saker-digital-kommunikation-DIS
Det finns även ett antal leverantörer som erbjuder SDK-komponenter, det finns ingen officiell lista över . SDK publicerar en lista med godkända mjukvaror från leverantörer (utöver accesspunkt som CEF tillhandahåller). som CEF tillhandahåller). Se Anslutna leverantörer i SDK Öppen testmiljö (ÖTM) och leverantörer med godkänd mjukvara för MT/MK
Etablering kan ske via befintlig avtal eller så kan en direktupphandling göras. SDK tillhandahåller dock inget kravunderlag även stöd i form av en kravkatalog för anskaffning, utöver de tekniska specifikationer som finns publicerade.
Genom att använda ett ramavtal får användarorganisationen stöd med kravställan och etablering av nödvändiga SDK komponenter.
Mer information om kravkatalog för anskaffning finns här: Kravkatalog för anskaffning
Sammanfattning:
Tips |
---|
Rekommendation: Bevaka SKL Kommentus kommande ramavtal för SDK komponenter Länk till SKL Kommentus - Säker digital kommunikation:
|
...
Vanliga frågor som kan accelerera användarorganisationens förstudiearbete.
Fråga | Svar |
---|---|
Meddelandeklient (verksamhetssystem) | |
Kravställer SDK i detalj hur en klient skall fungera?
| Nej |
Finns stöd för klientsignering (person signera meddelandet som skickas) | Nej |
Finns funktionalitet för att se om mottagaren har läst meddelandet? | Nej |
Finns det funktionalitet för att se om meddelandet har levererats till mottagaren (användarorganisation)? | Ja |
Får avsändaren ett felmeddelande om t.ex. mottagarens anslutning ligger nere? | Ja |
Är det bara PDF som får bifogas i SDK meddelanden? |
Nej | |
Adressboken | |
Finns personer eller personal Adressboken? | Nej |
Är det användarorganisationen som ansvarar för att underhålla adressuppgifter i adressboken | Ja |
Kan man synkronisera adressboken med t.ex. HSA eller lokal katalog. | Nej |
Hur hittar man rätt i adressboken? Finns det färdiga regler och kodverk för kodning av funktionsadresser? | Ja |
Är all information i SDK adressbok öppet tillgänglig på internet? | Ja |
Finns det ett öppet sök API till adressboken? | Ja |
Kan man använda e-post i SDK? | Nej |
Tekniska gränssnitt | |
Är APIer mellan Accesspunkt, meddelandetjänst och meddelandeklient standardiserade? | Nej |
SDKs källkod | |
Delar Inera källkod för Testbäddens komponenter (Testklient, auktorisation) | Nej |
Bilaga 1: Visuellt stöd vid implementation av lokala SDK-komponenter
...
Lucidchart | |||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
...
Lucidchart | ||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|