To je ale práve ten kameň úrazu. Podpisujúci nevidí, čo je v PDF vložené ako priložený súbor, ale podpíše to. V tom lepšom prípade sa aspoň dozvie, že v tom PDF súbore je aj nejaká príloha, ktorú tiež podpisuje. A aj v prípade, že to vidí, tak v prípade vloženého XML vidí obsah XML bez akejkoľvek vizualizácie pre “normálneho” človeka a nie technického geeka. Skúste si teraz predstaviť normálneho človeka, ktorý je rád, že zvládne kvalifikovane podpísať PDF dokument. A skúste takémuto človeku povedať, že by si mal skontrolovať aj obsah toho vloženého xml, lebo to tiež podpisuje. Prípadne by si mal porovnať s obsahom PDF aj obsah toho XML. A to ešte nikde nie je napísané, že to vložené XML - čo je vlastne súbor, má vôbec nejaký súvis so samotným PDF. Ak Vás pri tejto predstave nezamrazí, tak potom už neviem.
OK to co pises je pravda. Ja som sa skorej vyjadroval k tomu, ze Pdf je napr. uradny dokument a a to xml ze je data.xml ktory moze prijemca vyuzit. Cize podobne ako je to u faktur ZUGFERD podpisujuci vie ze tam priloha je resp. musi byt.
Napr. vyplneny data.xml formular sa pomocou XSL-FO transformuje do PdfA formatu a to data.xml sa do neho vlozi ako priloha. Pdf dokument sa podpise. Obcan dostane pdf subor ktory je pre neho praktickejsi a kto si potrebuje nieco zautomatizovat vytiahne si prilohu xml a pouzije ju.
Tak Apple to ma historicky prepojené cez iCloud Keychain + Secure Element hardwarovo. Jeden Passkey mi funguje automaticky na iPade, iPhone, Mac Studio a Macbooku bez problemov.
A pravdaže na Safari všade + som si skúsil aj Chrome a tam to ide tiež 
ZUGFeRD/Factur-X: XML or PDF: What do I have to use, check, respectively archive how?
In Germany, if you are a company, you will have to check and use XML (source https://www.dstv.de/wp-content/uploads/2023/10/BMF_2023-0922192-R.pdf) and archive also at least XML (GoBD page 30, §9.1 Maschinelle Auswertbarkeit). As customer, you can decide if you check&use XML or PDF. However, and despite the spec says the contents should be identical, due to possible fraud please do not check e.g. only the PDF and then pay the XML version. Unfortunately, if you wanted to auto detect deviations you need OCR and a invoice recognition and your results will most likely not be perfect.
Nechcel som tu vyvolat nejaku flame 
Odkazovany dokument hovori v podstate, že faktura obsahuje dve formy jednu citatelnu a druhu datovu. A ked je medzi nimi rozdiel, tak plati ta druha.
Inak ten format faktury nie je obrazkovym PDF ale je to riadny textovy pdf, cize da sa pouzit nastroj ktory skontroluje ci sa v texte nachadzaju hodnoty uvedene vo vlozenom XML. Nie je potrebne vykonat OCR
Nie je to tak, pre iCloud synchronizaciu Passkey sa ziaden “Secure Element/Enclave” nepouziva (a vseobecne pre Passkey na iOS/macOS). Skratka ten Passkey sa syncne na vsetky ziariadenia prihlasene v iCloud ucte. Moja otazka teda znela, ze ci sa viem prihlasit na vsetkych zariadeniach kde mam ten iCloud/Passkey (a tym padom mat aj X digitalnych kopii OP)
A vies teda?
“How Apple Passkeys Work
Apple’s passkey system is based on public-key cryptography. When a passkey is created, a key pair is generated: the public key is stored on the server, while the private key is securely stored in the device’s secure enclave.
The enclave is a dedicated hardware component that ensures the private key never leaves the device, providing enhanced security and protection against external attacks.
Passkeys are synced via iCloud Keychain to make them available across all Apple ecosystems. The process is further streamlined by using the device’s unlock mechanism for passwordless authentication, with the private key signing the login request.
The combination of the secure enclave for private key storage with an iCloud Keychain for synchronization makes Apple passkeys more secure yet highly convenient for users.”
To je pravda len z polovice (ale ano, tie kluce v pripade iCloudu su v secure-enclave). Ale su exportovatelne (!):
passkeys, because, despite being stored in the Secure Enclave, the private key is exported to iCloud and hence its strength is only as good as the iCloud recovery process. (zdroj: The good, the bad and the ugly of Apple Passkeys | SlashID Blog).
Rovnako ale MeID podporuje akykolvek password manager s podporou Passkeys (hovoria v dokumentacii o Bitwarden). Tam nefunguje ziadne secure-enclave a privatny kluc si jednoducho z neho exportujes.
Njn, výhoda uzavretého systému vs open. Ja osobne Passkeys považujem za modernú a bezpečnú technológiu. V konečnom dôsledku sú si za svoju bezpečnosť zodpovední samotní užívatelia. Vyber HW a SW je toho veľkou súčasťou.
Máte lokálny účet alebo MS?
Eh? Prečo by som mal byť na Windows? Ubuntu/Firefox.
Nainštalovať som, aktivoval a celkom ok.
Passkey sa mi uložil do pass mngr, čo som nečakal, ale už to tu niekto spomínal. Pridal som si dve zariadenia, tak sa ma to potom pýtalo ktoré použiť či niečo také, zvolil som always PC.
Teraz som sa išiel na inom PC prihlásiť a smola. Chcel som použiť mobil, ale neviem to zmeniť a nepodporovaný prehliadač na mobile tomu nepomáha 
No, asi treba pozrieť do manuálu…
Tak zase, keď sa budem nudiť.
Mne aktivácia zbehla iba v Chromium a na mobile, čiže zas je to pre určité % ľudí nepoužiteľné a navyše podľa všetkých zákonov a zásad, štandardov, noriem a vyhlášok, opäť je tu jasná diskriminácia a porušenie všetkých tých nariadení dokola znova a opäť.
Od 30.04.2025 už funguje aj na sluzby.orsr.sk 
Vo všeobecnosti podpísať čo nevidím je samozrejme mimoriadne rizikové. V tomto konkrétnom prípade vidím však niekoľko “ale”:
- V podpísanom PDF sú dve sady údajov. Jedna v texte, ktorá je aj zobrazená pred podpísaním, druhá v XML embedded file, ktorú používateľ nevidí. Čiže informácia, čo používateľ pri podpísaní skutočne videl (ehm, skôr mal vidieť) sa nestratí.
- Používateľ je systematicky informovaný, že vidí všetko čo podpisuje.
- Pravidlá (štandardy) sú nastavené tak, že obe sady údajov majú byť to isté.
- Povolené sú iba také PDF s embedded file, ktoré sú generované na ÚPVS, kde aplikácia má spoľahlivo vytvárať iba rovnaké sady údajov
Z toho mi vychádza, že v prípade rozdielnych údajov (vizualizovaný)text - XML by používateľ vedel ľahko preukázať, čo v skutočnosti zamýšľal podpísať a taktiež, že rozdielne XML od textu je chyba a nie jeho. Bez problémov by mal spor vyhrať - ale jasné, že vôbec nejaký spor mať a riešiť je už samotné zle.
V tomto skôr ako problém vyzerá situácia, kedy používateľ úmyselne vygeneruje PDF kde sú rozdielne údaje v texte a XML. Povedzme nejaké výkazy, kde sa deklaruje majetok/príjem - v texte bude skutočnosť, v XML nič. Používateľ podpíše a čaká, či sa na to príde. Ak nie, ušetril. Ak áno, bude sa obhajovať, že dokument chybne vygeneroval štátny systém a on s tým nič nemá.