[Xaxis]

This PR contains the following updates:

Package	Change	Age	Confidence
@orangecheck/me-client (source)	^0.56.0 → ^0.59.0
@orangecheck/site-kit (source)	^0.12.0 → ^0.16.0

---

Release Notes

orangecheck/oc-packages (@​orangecheck/me-client)

v0.59.0

Compare Source

Added

• signInWithOc and signInWithOcOutcome answer the popup's
  oc-signin-challenge with oc-signin-echo and the same nonce. They answer
  only the popup they opened, and only at its origin. me.ochk.io will use it
  to check that the page that opened the popup is the one named in
  opener_origin before it signs anything. A nonce that is not 16 to 128
  base64url characters gets no answer. The sign-in button gets it too.

Changed

• OcPopupAccount says that display_name and nostr_npub are null for
  any site outside orangecheck's own (the family origins auth-core lists),
  and SCOPE_IDS says that signing in gives such a site no name.

v0.58.0

Compare Source

Added

• bearerToken on oc.payment.authorize, for that call only, as on
  oc.event.fire. setBearerToken holds one token for the whole process, so a
  server serving many people passes each person's token per call instead. It
  is sent as Authorization and never in the body. setBearerToken still works.
• The five scopes me.ochk.io already knows and oc.scope.request refused:
  cross_integrator_lifetime_sats, cross_integrator_distinct_count,
  cross_integrator_oldest_event_at, cross_integrator_active_days and
  trust_attestations_bundle. Scope has all twelve, and SCOPE_IDS exports
  them, frozen, in the order me.ochk.io lists them; a me.ochk.io test fails when
  the two lists differ.

Deprecated

• The attest_tier scope, as me.ochk.io already marks it. ochk.app no longer
  asks for it, so a request for it asks the person nothing; a backed account
  tells your site what backs it at sign-in. Old grants still resolve. The
  oc.scope example asks for email and bitcoin_address instead.

Changed

• WebhookPayload.scopes is keyed by Scope, so it names the four cross-app
  scopes a delivery can carry beside the ones it already listed.

v0.57.0

Compare Source

Deprecated

• The display_name scope. Signing in already gives your site the person's
  display name, so ochk.app no longer offers the scope and me.ochk.io resolves
  it to nothing. oc.scope.request still accepts it, so nothing that asks for
  it breaks; read the name from the sign-in instead.

Changed

• With OC_REVOCATION_FEED_TOKEN unset, a family session (no aud) is now
  unavailable with reason: 'revocation_feed_unconfigured', and the adapters
  answer it 503 with that reason, where checkOcSession, getOcSession,
  withOcAuth, ocAuthExpress and ocAuthHono used to throw (0.44.0). It is
  still never read by its signature alone, reads and writes alike, and the
  first one logs which setting is missing. OcSessionUnavailable gains the
  reason.

Added

• A rejected entry in event.fireBatch's results can carry code, a
  BatchRejectCode to switch on, beside reason in words. me.ochk.io sends
  one on every rejected entry now; an older server sends reason alone, so
  code is optional.

Fixed

• oc.scope.granted works for an integrator: call it from your backend with
  accountId (the person's did:oc) and signingSecret, and it signs the
  question the way me.ochk.io's scopes route checks it. With neither, it reads
  the session the request carries, which only ochk.app's own pages have, so a
  browser on your site gets 401. Either option without the other, or an
  accountId that is not a did:oc, throws before any request.
• Session and SessionPolicy say what me.ochk.io sends and takes:
  issued_at (the type said opens_at, which never arrived), refresh
'sliding' | 'rolling' | 'fixed' and sensitive_actions 're-auth' | 'allow'. Code that read opens_at read undefined; read issued_at.
  oc.session.*'s doc and the README say these calls work only from
  ochk.app's own pages.
• A refusal whose words are in detail now carries them as the
  MeClientError's message: the event routes' project_auth_required 401
  and any route's row_busy 503. The message used to be the bare code.
  reason still comes first, and the code is the fallback when the body has
  no words.
• family.scopes' doc names its 401 by the code me.ochk.io sends,
  sign_in_required, not the old words.

orangecheck/oc-packages (@​orangecheck/site-kit)

v0.16.0

Compare Source

New entry ./session-recheck, for the browser. recheckOnSeveralSessions(status, body)
says whether a write's answer was 401 several_sessions and, when it was,
asks the page to read its session again. useSessionRecheck(refresh), mounted
once inside the session provider with its refresh, does that read. The page
then shows the account the browser sends now. Nothing sends the write again.

v0.15.0

Compare Source

The session reader passes the request's method to auth-core 2.30.0, so a
write that carries more than one oc_session cookie and no per-tab token
resolves to no session, with reason several_sessions. Reads, a write with
one cookie and a write pinned to a tab read as before. The auth-core peer
range is now ^2.30.0: an older auth-core reads such a write's first
cookie.

A site whose own reader refuses such a write can answer it with a way out.
answerSeveralSessions(req, res) answers 401
{ ok: false, reason: 'several_sessions' }, no-store, with a clear for every
stray oc_session the request's path carried: host-only cookies at every
prefix of the path, and cookies at the auth host's domain (OC_AUTH_ISSUER's
host, when the request's host sits under it) at every prefix but /. The
cookie at that domain and / stays, so the same request sent again carries
one cookie. A reader throws SeveralSessions and answersUnverified answers
it that way. severalSessionsRefused(req) says whether a request is one the
rule refuses, and strayCookieClears(url, domain) gives the clears alone.
After that 401 a page reads the session again and shows it before the person
sends the write again: the cookie left can be another account than the one the
page showed.

v0.14.0

Compare Source

A site that holds a person's data can answer every API route the way its
/api/auth/me answers while the auth host's list of ended sessions can't
vouch for a session. Its session reader throws SessionUnverified, and a
route exported through answersUnverified(handler) answers that with 503
{ ok: false, error: 'session_unverified' }, Retry-After: 60 and
Cache-Control: no-store, private, for a read as for a write; any other
error passes through, and so does SessionUnverified once the route has
started its answer. answerSessionUnverified(res) writes the same answer,
and createMeHandler now writes its 503 through it.

v0.13.0

Compare Source

A site that holds a person's data can refuse reads too while the auth
host's list of ended sessions can't vouch for a session.
createSessionReader({ refuseUnverifiedReads: true }) refuses every method
with reason unverified in that state, and createMeHandler answers that
reason with 503 { ok: false, error: 'session_unverified' },
Retry-After: 60 and no-store, for a cookie or a per-tab token alike,
without asking the fallback. auth-client reads the 503 as an error and keeps
the account and the tab's pin. A reader made without the option is
unchanged: reads pass, writes are refused.

---

Configuration

📅 Schedule: (in timezone UTC)

• Branch creation
  • Between 02:00 AM and 09:59 AM (* 2-9 * * *)
• Automerge
  • At any time (no schedule defined)

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

👻 Immortal: This PR will be recreated if closed unmerged. Get config help if that's undesired.

---

• If you want to rebase/retry this PR, check this box

---

This PR has been generated by Mend Renovate CLI.

[Xaxis]

Carried by 376234a (PR #510): me-client 0.59.0 and site-kit 0.16.1, CI and deployment green, the live sign-in-button page serves the 0.59.0 SRI pins.