UCP w 2026: co nowego w standardzie — klucze, Web Bot Auth i zgody kupującego

Jeśli śledzisz nasz blog, wiesz już, czym jest Universal Commerce Protocol (UCP) — otwarty standard, który pozwala agentom AI (ChatGPT, Gemini i innym) czytać ofertę Twojego sklepu i realizować zakupy przez ustandaryzowane API, zamiast zgadywać, co robi który przycisk. Standard nie stoi jednak w miejscu. Najnowsza oznaczona wersja to 2026-04-08, ale prace na gałęzi rozwojowej idą dalej — i w ostatnich tygodniach pojawiło się kilka zmian, które warto znać, zanim zaczniesz (lub kończysz) wdrożenie.

Poniżej przegląd tego, co się zmieniło, po ludzku — i co to oznacza dla właściciela e-commerce.

1. Klucze podpisu przeniesione do pola keys[]

To najważniejsza zmiana techniczna. UCP ujednolicił sposób, w jaki sklep publikuje swoje klucze publiczne — służące do weryfikacji, że manifest i odpowiedzi API naprawdę pochodzą od Ciebie, a nie od kogoś, kto się pod Ciebie podszywa.

Wcześniej klucze bywały opisywane pod różnymi nazwami. Dziś kanoniczne jest jedno pole: keys[] w korzeniu dokumentu profilu, obok obiektu ucp. Jest to zbiór kluczy w formacie JWK (JSON Web Key Set, RFC 7517):

{
  "ucp": {
    "version": "2026-04-08",
    "services": { "dev.ucp.shopping": [ /* ... */ ] },
    "capabilities": { /* ... */ },
    "payment_handlers": { /* ... */ }
  },
  "keys": [
    {
      "kid": "key-2026",
      "kty": "EC",
      "crv": "P-256",
      "x": "…",
      "y": "…",
      "use": "sig",
      "alg": "ES256"
    }
  ]
}

Praktyczny wniosek: jeśli publikowałeś klucze pod starą nazwą, przenieś je do keys[]. To jedno pole jest teraz „miejscem, z którego każdy weryfikator UCP odczytuje klucze”. Nasz checker na ucpcommerce.pl/score sprawdza już poprawnie to nowe pole.

2. Web Bot Auth — agent, który udowadnia, kim jest

Publikacja keys[] ma drugie, ważne zastosowanie. Ten sam zbiór kluczy pozwala włączyć Web Bot Auth (WBA) — mechanizm, w którym agent AI podpisuje kryptograficznie swoje żądania (przez tzw. HTTP Message Signatures), a Twój serwer może zweryfikować ten podpis.

Dlaczego to istotne? Bo zmienia pytanie „czy wpuścić tego bota?” z gry w zgadywanie po nazwie User-Agent (którą łatwo sfałszować) na weryfikowalny fakt. Sklep może odróżnić prawdziwego agenta zakupowego od ruchu podszywającego się pod niego — i np. udostępnić zaufanym agentom pełne API checkoutu, a resztę traktować ostrożniej.

W skrócie: keys[] to nie tylko „pieczątka autentyczności” Twojego sklepu. To także fundament, na którym agenci budują zaufaną, uwierzytelnioną komunikację z Tobą.

Dodaliśmy właśnie do naszego scoringu osobny, bonusowy sygnał „Gotowość Web Bot Auth” — punktowany, gdy sklep publikuje poprawny zestaw kluczy JWK.

3. Zgody kupującego (buyer consent)

Standard doprecyzował, jak przekazywać zgody kupującego — z podziałem na segmenty (per-segment). W praktyce chodzi o to, by agent działający w imieniu użytkownika mógł w ustrukturyzowany, rozszerzalny sposób przekazać, na co klient faktycznie wyraził zgodę (np. przetwarzanie danych, marketing, warunki konkretnej transakcji). Dla e-commerce działającego w realiach RODO to porządkuje odpowiedzialność: zgoda jest jawną, przenoszalną częścią transakcji, a nie domysłem.

4. Delegowana tożsamość i szybsze logowanie

Pojawiła się obsługa delegowanych dostawców tożsamości oraz przyspieszonego przepływu logowania (accelerated IdP). Cel: gdy agent robi zakup dla zalogowanego klienta (żeby zobaczył ceny lojalnościowe, historię zamówień czy zapisane adresy), połączenie tożsamości ma przebiegać płynnie i bezpiecznie — bez zmuszania użytkownika do przeklikiwania pełnego logowania przy każdej interakcji.

5. Metody dostawy widoczne już w katalogu

Kolejna zmiana przenosi informacje o fulfillment (metodach i opcjach dostawy) na poziom katalogu — agent może poznać dostępne sposoby i warunki dostawy wcześniej, jeszcze zanim zbuduje koszyk. Dla klienta końcowego oznacza to trafniejsze rekomendacje („dostępne od ręki, z dostawą jutro”) już na etapie porównywania ofert.

Do tego doszło uszczelnienie zarządzania przestrzenią nazw (reverse-domain, np. dev.ucp.shopping.checkout) — sprawa istotna dla implementujących standard, mniej odczuwalna dla właściciela sklepu.

Gotowość to nie to samo co certyfikacja — skąd bierze się nasz wynik

Przy tej okazji warto rozwiać częste nieporozumienie. W ekosystemie UCP istnieją dwa różne poziomy sprawdzania sklepu, które łatwo pomylić:

• Gotowość (readiness) — to, co robi nasz checker na ucpcommerce.pl/score. Z zewnątrz, bez logowania i bez wykonywania jakichkolwiek transakcji, pobieramy publiczne sygnały: manifest UCP, robots.txt, dane strukturalne, a także wykonujemy lekki, wyłącznie odczytowy „handshake” z zadeklarowanymi endpointami (MCP initialize, karta agenta A2A). Wynik 0–100 mówi: „jak dobrze Twój sklep jest wykrywalny i zadeklarowany dla agentów AI”. To pierwszy filtr — szybki, bezpieczny, możliwy do uruchomienia dla dowolnej domeny.

• Zgodność (conformance) — to osobne, znacznie cięższe narzędzie: oficjalny zestaw testów zgodności UCP. To wykonawcze testy integracyjne (w Pythonie), które uruchamia się przeciwko działającemu serwerowi UCP i które realnie przeprowadzają pełne przepływy: tworzenie, aktualizację, anulowanie i finalizację checkoutu, zamówienia, dostawę, webhooki, idempotencję czy płatności agentowe (AP2). Wymagają zainicjowanej bazy danych z danymi testowymi i sekretu symulacji — dlatego uruchamia je implementer przeciwko własnej implementacji (zwykle w CI), a nie audytor z zewnątrz.

Innymi słowy: nasz /score odpowiada na pytanie „czy jesteś widoczny i poprawnie zadeklarowany?”, a repozytorium conformance — na pytanie „czy Twój serwer zachowuje się dokładnie tak, jak wymaga protokół, w każdym scenariuszu transakcji?”. To dwa uzupełniające się kroki: najpierw wykrywalność i deklaracja, potem behawioralna certyfikacja. Świadomie nie próbujemy odtwarzać testów conformance przeciwko cudzym sklepom — wymagałoby to wykonywania realnych transakcji i autoryzacji, co byłoby i niebezpieczne, i niewłaściwe.

Co z tym zrobić?

Standard dojrzewa, a okno przewagi się nie domknęło. Jeśli dopiero zaczynasz, zadbaj o fundamenty (widoczność, poprawny manifest, keys[]). Jeśli masz już manifest — sprawdź, czy nadążasz za nowszymi elementami: kluczami i Web Bot Auth, zgodami, tożsamością, dostawą w katalogu.

Pierwszy, bezpłatny krok to sprawdzenie, na czym stoisz: wpisz adres swojego sklepu w naszym checkerze gotowości UCP. A jeśli chcesz omówić wdrożenie nowszych elementów standardu albo przygotowanie serwera do formalnej certyfikacji zgodności — umów się na bezpłatną konsultację z naszym zespołem.