Kan ni ge exempel på värden som används vid slagning mot DIGG Certifikatspubliceringstjänst för att kryptera meddelandet?

(fråga relaterad till presentation av kodexempel, /wiki/spaces/OISDK/pages/2710929531

Accesspunktsidentitet: Accesspunktsoperatörs ID som tilldelats av DIGG till AP-operatör vid anslutning. Detta värde används vid konfiguration av AP:n och är även med i CN på det cert ni fått av DIGG samt del av PartyId (En accesspunkt kan serva flera organisationer). Exempel: AP-0001

ParticipantIdentifier: Identifierar användarorganisation i federationen och registreras av användarorganisationens AP-operatör, har formatet "0203:somedomain.se".

SML Zone: Beror på miljö. Se /wiki/spaces/OISDK/pages/2710012582

documentidentifier scheme: "busdox-docid-qns", se SDK Innehållsspecifikation Meddelande
participantidentifier scheme: "iso6523-actorid-upis", se DIGG eDelivery kuvreteringsprofil XHE

DocumentId SDK dokument (Meddelande, hanteras av SDK-federationen):
"urn:riv:infrastructure:messaging:MessageWithAttachments:3::messagePayload##3.0::tm-base-ext-sigenc", se SDK Innehållsspecifikation Meddelande

DocumentId för kvittering (Meddelandekvittens, hanteras av DIGG) :
"urn:oasis:names:specification:ubl:schema:xsd:ApplicationResponse-2::ApplicationResponse##fdc:digg.se:edelivery:messagetype:response:1::2.1::tm-base-ext-sigenc", se DIGG eDelivery Meddelandespecifikation Meddelandekvittens

Är det krav på vilket servercert vi kommer med då vi ansluter mot SDK adressboken adressbok i SDK Testbädd (QA) (och i SDK PROD)?

Nej, däremot så är det viktigt att säkerställa att man kommunicerar mot "rätt" SDK Adressbok.

Från IT-säkerhetsbilaga till regelverk för anslutning till Säker digital kommunikation – Informationssäkerhet (se Informationssäkerhet ):
Om anslutet system/backend-system använder SDK Adressboks API för direktsökning eller skapar en lokal läskopia av SDK Adressbok ska:

• Tillförlitlig källa enligt anvisning från SDK-federationsoperatör säkerställas genom kontroll av tjänstens “Sök-API” med TLS-certifikat.Transportkryptering tillämpas enligt generella krav på protokoll och krypteringsalgoritmer

Ett exempel på händelse som ska generera en felkod är "referens till meddelande (refToMessageId) som är markerat som REJECTED" (se SDK Innehållsspecifikation Meddelande), men hur kan det uppstå?

Scenario:

1. Användarorganisation A skickar ett meddelande

2. Användarorganisation B (MT) tar emot meddelandet och skickar en fördröjd ‘OK’ meddelandekvittens, där fördröjning innebär att det uppstår en timeout på användarorganisation A’s sida (MT)

3. Användarorganisation A (MT) tar emot den fördröja meddelandekvittensen, det efter att ha markerat ursprungsmeddelandet som okvitterat. Exakt hur MT sen skall hantera kvittensmeddelandet är ett lokalt beslut.

4. Användarorganisation B (som är ovetandes om timeouten hos användarorganisation A) skickar ett svarsmeddelande (med refToMessageId)

5. Användarorganisation A (MT) tar emot svarmeddelandet svarsmeddelandet och skickar en ‘REJECTED’ meddelandekvittens

Hur kan jag som avsändare veta vilken version(-er) som aktuell mottagare stödjer? Är det via adressbokenSDK Adressbok? Hittar inte informationen i API’et och tänker att den måste vara publikt tillgänglig.

I SMP registreras användarorganisationer som deltagare tillsammans med vilken major version av dokumenttypen som respektive användarorganisationer deltagare stödjer. Adressboken innehåller idag inte vilken version av dokumenttyp som stöds.

Hur är det tänkt kring minor-versioner som teoretiskt är möjliga. Om man tillför ”ett nytt frivilligt fält” i schemat borde väl det vara tvunget att alla meddelandetjänster måste uppdateras?

Om en minor version skulle släppas så kommer RIV-TAs regelverk för tjänsteschema tillämpas: https://rivta.se/documents/ARK_0005/RIV_Tekniska_Anvisningar_Tjansteschema.pdf

Hur säkerställer man att giltig version av payload nyttjas? Finns det uttryckt och i så fall var?

Validering av dokumenttyp sker i följande steg:

1. AP-Operatör: Skall säkerställa att kuvertering är korrekt. Detta görs på AS4 nivå samt inre kuvert XHE kuvert (DIGGs ’Kuverteringsprofil XHE’)

   T.ex. 

    <xha:BusinessScopeCriterion>

           <BusinessScopeCriterionTypeCode>DOCUMENTID</BusinessScopeCriterionTypeCode>

           <BusinessScopeCriterionValue>urn:riv:infrastructure:messaging:MessageWithAttachments:3::messagePayload##3.0::tm-base-ext-sigenc</BusinessScopeCriterionValue>

         </xha:BusinessScopeCriterion>

   …

    <xha:Payload>

         <DocumentTypeCode>messagePayload</DocumentTypeCode>

         <ContentTypeCode>urn:riv:infrastructure:messaging:MessageWithAttachments:3</ContentTypeCode>

   …

2. Användarorganisation: Meddelandetjänst -MT (Specifikation av validering, felhantering och kvittensSpecifikation av validering, felhantering och kvittens ) - ska efter dekryptering validera nyttolast mot schema.
   Så mottages ett meddelande som på AS4/XHE är “MessageWithAttachments:3” så skall MT schemavalidera med den versionen. Här ingår även schematronvalidering.

Var finns blankett för registrering av testdeltagare deltagare till DIGG SDK-QA-miljö?

Det är DIGG som äger dokumentet. Begär ut informationspaketet via ‘info@digg.se’.

Var finns SDKs anslutningsblanketter?

För ytterligare info, se SDK Anslutningsprocess för användarorganisationer

Finns det någon deltagare som är registrerad och uppe publicerad i SMP (DIGG i DIGGs SDK-QA)-miljö?

SDK har följande participantIdentifier registrerad och publicerad i DIGG DIGGs SDK-QA (SDK Testbädd)-miljö: 0203:testbed.inera.se