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 i SDK Testbädd (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.

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 och skickar en ‘REJECTED’ meddelandekvittens

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

I SMP registreras användarorganisationer tillsammans med vilken major version av dokumenttypen som respektive användarorganisationer 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 till DIGG SDK-QA?

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

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

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

Var finns blankett för registrering av testdeltagare till DIGG PilotPROD?

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