@ksvedal/docs 0.1.0

package/dist/token_lifetimes-Cp22x6RM.js

@@ -0,0 +1,17 @@
+const e = `# Tokenlevetid
+
+## Access token levetid
+
+Levetiden til access token bestemmer hvor lenge et utstedt token kan brukes mot et API. Kort levetid begrenser skadeomfanget hvis et token kommer på avveie, men gjør også at klienten oftere må hente nye token.
+
+## Autorisasjon levetid
+
+Autorisasjon levetid beskriver hvor lenge en gitt autorisasjon eller godkjenning kan ligge til grunn for videre tokenutstedelse. Dette er ikke nødvendigvis det samme som levetiden til selve access tokenet.
+
+## Praktisk avveining
+
+Det er vanlig å velge kortere levetid for sensitive tilganger og lengre levetid der hyppig fornyelse skaper unødvendig kompleksitet. Begge verdiene bør sees i sammenheng med risiko og brukeropplevelse.
+`;
+export {
+  e as default
+};

package/dist/token_lifetimes-CwzcMEnb.js

@@ -0,0 +1,17 @@
+const e = `# Token lifetimes
+
+## Access token lifetime
+
+The access token lifetime decides how long an issued token can be used against an API. A short lifetime limits the impact if a token is leaked, but also means the client must obtain new tokens more often.
+
+## Authorization lifetime
+
+Authorization lifetime describes how long a given authorization or approval can remain valid as the basis for issuing tokens. This is not necessarily the same as the lifetime of the access token itself.
+
+## Practical trade-off
+
+It is common to choose shorter lifetimes for sensitive access and longer lifetimes where frequent renewal creates unnecessary complexity. Both values should be evaluated together with risk and user experience.
+`;
+export {
+  e as default
+};

package/dist/token_type-B8DCg80j.js

@@ -0,0 +1,17 @@
+const e = `# Token type
+
+## SELF_CONTAINED
+
+A \`SELF_CONTAINED\` token typically carries the information the receiver needs directly in the token, for example as claims in a JWT. This makes validation fast and independent of an extra lookup, but it can also produce larger tokens and expose more information on the client or API side.
+
+## OPAQUE
+
+An \`OPAQUE\` token is usually only a reference. The API must then look up or introspect the token to retrieve the associated information. This gives more centralized control, but also creates a dependency on the lookup mechanism.
+
+## Practical choice
+
+Token type should be selected based on performance needs, control, complexity, and how much information should live directly inside the token.
+`;
+export {
+  e as default
+};

package/dist/token_type-C7Y04-Fc.js

@@ -0,0 +1,17 @@
+const e = `# Token type
+
+## SELF_CONTAINED
+
+Et \`SELF_CONTAINED\` token inneholder typisk informasjonen mottakeren trenger direkte i tokenet, for eksempel som claims i et JWT. Det gjør validering raskt og uavhengig av et ekstra oppslag, men kan gi større token og mer informasjon på klient- eller API-siden.
+
+## OPAQUE
+
+Et \`OPAQUE\` token er normalt bare en referanse. API-et må da slå opp eller introspektere tokenet for å finne tilhørende informasjon. Dette gir mer sentral kontroll, men skaper også avhengighet til oppslagsmekanismen.
+
+## Valg i praksis
+
+Token type bør velges ut fra behov for ytelse, kontroll, kompleksitet og hvor mye informasjon som bør ligge direkte i tokenet.
+`;
+export {
+  e as default
+};

package/dist/treemap-KMMF4GRG-DNEhU-LQ.js

@@ -0,0 +1,5 @@
+import { T as a, h as m } from "./mermaid-parser.core-C-16ojim.js";
+export {
+  a as TreemapModule,
+  m as createTreemapServices
+};

package/dist/user_involvement-4nbn_fQ7.js

@@ -0,0 +1,17 @@
+const e = `# User involvement
+
+## What does this cover?
+
+User involvement describes whether the end user must actively do something before access is granted or maintained. In the screenshot, examples include \`Krev reautentisering\` and \`Krev godkjenning fra sluttbruker\`.
+
+## Re-authentication
+
+If re-authentication is required, the user must confirm their identity again before the action or data sharing can continue. This is typically used for higher-risk or more sensitive actions.
+
+## End-user approval
+
+When approval from the end user is required, consent or explicit acceptance becomes part of the flow. This fits scenarios where the user must control whether data sharing or access should be allowed.
+`;
+export {
+  e as default
+};

package/dist/user_involvement-COT572uK.js

@@ -0,0 +1,17 @@
+const e = `# Brukerinvolvering
+
+## Hva dekker dette?
+
+Brukerinvolvering handler om hvorvidt sluttbrukeren må gjøre noe aktivt for at tilgang skal gis eller opprettholdes. I skjermbildet ser vi eksempler som \`Krev reautentisering\` og \`Krev godkjenning fra sluttbruker\`.
+
+## Reautentisering
+
+Hvis reautentisering kreves, må brukeren bekrefte identiteten sin på nytt før handlingen eller delingen kan fortsette. Dette brukes gjerne ved høyere risiko eller når handlingen er særlig sensitiv.
+
+## Godkjenning fra sluttbruker
+
+Når sluttbrukeren må gi godkjenning, blir samtykke eller eksplisitt aksept en del av flyten. Dette passer når brukeren selv må kontrollere om deling av data eller tilgang skal være tillatt.
+`;
+export {
+  e as default
+};

package/dist/visibility-BSqCGXMv.js

@@ -0,0 +1,17 @@
+const e = `# Visibility
+
+## What do PUBLIC and PRIVATE mean?
+
+Visibility decides how visible the scope is to other users or organizations in the solution. A \`PUBLIC\` scope can typically be discovered and reused more broadly, while a \`PRIVATE\` scope is more restricted and intended for controlled scenarios.
+
+## When to use PRIVATE
+
+\`PRIVATE\` is often the right choice when access needs tight control, when the scope should only be used by known parties, or when it represents internal or sensitive API access.
+
+## When to use PUBLIC
+
+\`PUBLIC\` can make sense when the scope should be easy to find and use for many consumers, and when the access process is clear enough that broader exposure is desirable.
+`;
+export {
+  e as default
+};

package/dist/visibility-CidZ07d9.js

@@ -0,0 +1,17 @@
+const e = `# Synlighet
+
+## Hva betyr PUBLIC og PRIVATE?
+
+Synlighet avgjør hvor synlig scopet er for andre brukere eller virksomheter i løsningen. Et \`PUBLIC\` scope kan typisk oppdages og gjenbrukes bredere, mens et \`PRIVATE\` scope er mer begrenset og ment for kontrollerte scenarioer.
+
+## Når brukes PRIVATE?
+
+\`PRIVATE\` er ofte riktig når tilgang skal styres tett, når scopet bare skal brukes av kjente aktører, eller når scopet beskriver en intern eller sensitiv API-tilgang.
+
+## Når brukes PUBLIC?
+
+\`PUBLIC\` kan passe når scopet skal være enkelt å finne og ta i bruk for mange, og når tilgangsprosessen rundt scopet er tydelig nok til at bredere eksponering er ønskelig.
+`;
+export {
+  e as default
+};