CZ20013150A3 - Oboustranné ověřování zpráv v datové síti pomocí automatického inkrementálního předkládání pověřovacích informací - Google Patents
Oboustranné ověřování zpráv v datové síti pomocí automatického inkrementálního předkládání pověřovacích informací Download PDFInfo
- Publication number
- CZ20013150A3 CZ20013150A3 CZ20013150A CZ20013150A CZ20013150A3 CZ 20013150 A3 CZ20013150 A3 CZ 20013150A3 CZ 20013150 A CZ20013150 A CZ 20013150A CZ 20013150 A CZ20013150 A CZ 20013150A CZ 20013150 A3 CZ20013150 A3 CZ 20013150A3
- Authority
- CZ
- Czechia
- Prior art keywords
- credentials
- party
- data processing
- request
- credential information
- Prior art date
Links
- 230000004044 response Effects 0.000 claims abstract description 7
- 238000000034 method Methods 0.000 claims description 95
- 238000012545 processing Methods 0.000 claims description 62
- 230000008569 process Effects 0.000 claims description 10
- 238000004590 computer program Methods 0.000 claims description 3
- 230000001419 dependent effect Effects 0.000 claims description 2
- 238000001514 detection method Methods 0.000 claims 1
- 238000013459 approach Methods 0.000 description 13
- 230000035945 sensitivity Effects 0.000 description 6
- 238000004891 communication Methods 0.000 description 4
- 230000008520 organization Effects 0.000 description 4
- 238000013475 authorization Methods 0.000 description 3
- 238000012790 confirmation Methods 0.000 description 3
- 238000010586 diagram Methods 0.000 description 3
- 238000009795 derivation Methods 0.000 description 2
- 238000005516 engineering process Methods 0.000 description 2
- 230000008901 benefit Effects 0.000 description 1
- 125000004122 cyclic group Chemical group 0.000 description 1
- 238000012217 deletion Methods 0.000 description 1
- 230000037430 deletion Effects 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 230000007246 mechanism Effects 0.000 description 1
- 238000004886 process control Methods 0.000 description 1
- 238000011160 research Methods 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
- G06F21/44—Program or device authentication
- G06F21/445—Program or device authentication by mutual authentication, e.g. between devices or programs
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Software Systems (AREA)
- Computer Hardware Design (AREA)
- General Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Signal Processing (AREA)
- Computer Networks & Wireless Communication (AREA)
- Computing Systems (AREA)
- General Physics & Mathematics (AREA)
- Physics & Mathematics (AREA)
- Information Transfer Between Computers (AREA)
- Storage Device Security (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
- Lock And Its Accessories (AREA)
- Computer And Data Communications (AREA)
- Communication Control (AREA)
Description
INFORMACÍ
Oblast techniky
Vynález se týká oblasti nasazeni počítačů klient/server (také známého jako distribuovaného), kde jedno výpočetní zařízení (klient) žádá jiné výpočetní zařízení (server), aby provedlo část klientovy práce.
Dosavadní stav techniky
Nasazení počítačů klient/server je ve světě informačních technologií během posledních několika let stále důležitější. Tento typ distribuovaného nasazení počítačů umožňuje softwarovému procesu (např. klientovi) běžícímu na jednom stroji delegovat část své práce softwarovému procesu (např. serveru) běžícímu na jiném stroji, který se například může lépe hodit k provedení této práce. Klient a server mohou být také oddělené softwarové procesy běžící na stejném stroji.
V takovýchto systémech klient/server je velmi důležité, aby si klient a server vyvinuly dostatečnou úroveň vzájemné důvěry před tím, než se zapojí do smysluplné komunikace, protože informace, které se mohou vyměnit během klientova požadavku na zpracování serverem a/nebo výsledek zpracování serverem, který se vrací klientovi, mohou být vysoce citlivé
82725 (2782725_CZ.doc) informace. Klient se serverem často neměli žádný předchozí vzájemný vztah, a tedy musí vstoupit do nějakého druhu počáteční konverzace, aby se určilo, zda si mohou vzájemně věřit, před tím, než předloží jakékoliv potenciálně citlivé informace. Dobrý příklad toho, kde je toto zvlášť užitečné je, když je klientem aplikace prohlížeče World Wide Web posílající internetem elektronické obchodní požadavky serverové World Wide Web aplikaci. Na počátku komunikace mezi těmito stranami nemají Webovský klient a Webovský server žádný předchozí vztah a Webovský klient může například velmi neochotně poskytovat Webovskému serveru přes Internet číslo kreditní karty.
Z dřívějšího stavu l informaci (tj .
vystavovatelem mezi klientem a pověřovacích pověřuj ícím informaci) techniky je známá výměna digitálně podepsaných tvrzení o vlastníkovi pověřovacích mezi nimi vytvořila s použitím ověřeny Pověřovací serverem, aby se důvěra. Pověřovací informace jsou podepsány vlastníka, vystavovatelova soukromého použitím vystavovatelova informace shrnují jednu přičemž každý atribut se mohou být veřejného nebo více klíče a klíče.
atributů skládá ze dvoj ice název/hodnota a popisuje nějakou vlastnost vlastníka, kterou tvrdí vystavovatel. Každá pověřovací informace také obsahuje veřejný klíč vlastníka pověřovacích informací. Vlastník může použít odpovídající soukromý klíč, aby odpověděl na výzvy nebo jinak prokázal vlastnictví pověřovacích informací. Vlastník může také použít soukromý klíč k podepsání jiných pověřovacích informací vlastněných třetí entitou.
Jak je tedy známo z předchozího stavu techniky, pověřovací informace mohou být zkombinovány do řetězců, kde vlastník jedné pověřovací informace je vystavovatelem další (2782725_CZ.doc) pověřovaci informace v řetězci.
Tyto řetězce se mohou předkládat ke sledování sítě důvěry od známé entity (vystavovatele první pověřovaci informace předkládáj ici entitě, ve kterou je třeba důvěru získat.
Předkládáj ici entita je vlastníkem poslední pověřovaci informace v řetězci.
Předkládající entita může prokázat vlastnictví této pověřující informace prokázáním držení součásti soukromého klíče od veřejného klíče v ní obsaženého. Jiné podpůrné pověřovaci informace vlastní entity, se kterými má předkládající entita přímé nebo nepřímé vztahy, a přestože je předkládající entita nevlastní, předkládající entita schovává a předkládá jejich kopie. Každá podpůrná pověřovaci informace obsahuje veřejný klíč, přičemž k němu patřící soukromý klíč se použil k podepsání následující pověřovaci informace v řetězci.
Všechny předložené pověřovaci informace se vztahují k prokázání (i nepřímému) vztahu mezi předkládající entitou a známou entitou, která vystavila první pověřovaci informaci v řetězci. Povahu vztahu lze dovodit prohlížením atributů pověřovacích zpráv v řetězci. Lze předložit více řetězců, aby se dosáhlo vyšší úrovně důvěry, nebo aby se prokázaly další vlastnosti předkládající entity a jejích vztahů se známými entitami.
Dosavadní stav techniky pro použití pověřovacích informací k navázání oboustranné důvěry lze rozdělit na dva základní přístupy. První přístup popisuje A. Frier, P. Karlton a P. Kocher, The SSL 3.0 Protocol, Netscape Communications Corporation, 18. listopadu 1996; T. Dierks, C. Allen, The TLS Protocol Version 1.0, draft-ietf-tlsprotocol-06.txt, 12. listopadu 1998; S. Farrell, TLS Extensions for Attribute Certificate Based Authorization, (2782725_CZ.doc) • ·
draft-ietf-tls-attr-cert-01.txt, 20. srpna 1998. Tomuto přístupu budeme říkat přístup SSL, protože se používá pro SSL, TLS a TLS s rozšířeními pro oprávnění založená na potvrzování atributů. V přístupu SSL si mohou klient a server vyměňovat pověřovací informace následovně. Server naváže vyjednáváni jednostranným předložením předem vybrané pověřovací informace.
Ta může obsahovat požadavek na klientovy pověřovací informace včetně typu pověřovací informace, který může server přijmout, a v případě potvrzování atributů šablonu označující požadované atributy.
Druhý přístup popisuje N. Ching, V. Jones a M. Winslet,
Authorization in the Digital Library: Secure Access to
Services across Enterprise Boundaries, zpráva ADL '96 --Fórum výzkumu a technologických pokroků knihovnách, Washington, DC, Květen 1996, http://drl.cs.uiuc.edu/security/pubs.html;
v digitálních přístupná na a také
M. Winslett, N. Ching, V. Jones a I. Slepchin, Using
Digital Credentials on the World-Wide Web, Journal of
Computer Security, 5, 1997, 255-267, přístupné na http://drl.cs.uiuc.edu/security/pubs.html. Tomuto druhému přístupu budeme říkat přístup digitálních pověřovacích informací. Pokud v tomto přístupu dojde k požadavku na službu od klienta na serveru bez přiložených odpovídajících pověřovacích informací, server pošle klientovi postup ovládající tuto službu. Postup je vzorec pověřovací informace, to znamená logická kombinace požadovaných pověřovacích informací a vyjádření omezujících podmínek atributů, které obsahují. Postupy lze použít k vyznačení požadovaných vlastností předkládající entity a jejích vztahů se známými entitami. Obdržením tohoto postupu jako požadavku na pověřovací informace má klient možnost vybrat v soukromí pověřovací informace k předložení, aby se potvrdila služba.
(2782725_CZ.doc) • v ···· · «· · · • · « ···· ··· • · · » · · Λ
Zasláním postupů klientům servery odsunou zatížení spojené s výběrem pověřovacích informací. To také umožňuje různým serverům mít velmi odlišné postupy požadující různé klientské atributy a přijímat pověřovací informace vystavené různými autoritami.
Oba tyto přístupy podle dosavadního stavu techniky podporují odeslaní požadavku serveru na pověřovací informace klienta včetně charakterizace pověřovacích informací, které by pro server byly přijatelné. Avšak vynálezci zaznamenali na tomto současném stavu techniky následující nedostatky.
V SSL přístupu neexistuje pro server žádná možnost ověřit si jakékoliv informace o klientovi před tím, než předloží pověřovací informace serveru. Server může považovat své pověřovací informace za vysoce důvěrné, a pokud tedy selže navázání oboustranné důvěry mezi klientem a serverem, potom server poslal klientovi vysoce citlivou (důvěrný) část informací. Dále, pokud pověřovací informace předložené serverem klienta neuspokojí, klient nemá žádnou šanci požadovat od serveru doplňující pověřovací informace. To může být vážný problém, když nemají server a klient žádný předchozí vztah. V tomto případě je nepravděpodobné, aby byl jakýkoliv jediný vystavovatel pro všechny klienty přijatelnou zárukou za všechny zajímavé atributy serveru.
Nedokonalost dřívějších systémů založených na přístupu digitálních pověřovacích informacích vyvstává u pověřovacích informací, které si klient přeje předložit pouze serverům, se kterými si již vybudoval určitý stupeň důvěry. Dřívější systémy vyvinuté s použitím přístupu digitálních pověřovacích informací podporovaly předkládání postupů pro klientovy pověřovací informace, které rozdělily služby do (2782725_CZ.doc) tříd ekvivalence a potom pro každou třídu ekvivalence přidělily každou klientovu pověřovací informaci do jedné ze dvou kategorií. Pověřovací informace v první kategorii mohly být předloženy s jakýmkoli požadavkem na službu ve třídě ekvivalence. Ty ve druhé kategorii mohly být předloženy pouze po vzájemné konzultaci s uživatelem pro oprávnění. Tyto konzultace umožňovaly uživateli přesunout pověřovací informace z druhé kategorie do první, což umožnilo následné automatické předložení. Avšak tento mechanismus není zcela automatický v tom, že potřebuje, aby byl uživatel přístupný k provedení rozhodnutí o důvěře, když se naváže spojení s novými třídami služeb.
V rámci přístupu digitálních pověřovacích informací,
Winslett a kol. (citovaní výše) stručně popisují alternativní metodu, kde může klient vyžadovat pověřovací informace serveru, aby odemkl přístup ke svým pověřovacím informacím. Tento způsob lze použít k implementaci vyjednávání, ve kterém je od každého zúčastněného jediný požadavek na pověřovací informace. Každá služba je spojena s postupem, který server pošle klientovi, když klient tuto službu požaduje. Když se role obrátí, není jasné, z jakého důvodu by měly servery poskytovat pověřovací informace klientům. Jedna možnost je, aby se získala klientova důvěra pro obecné účely spolupráce se serverem. Další možnost je získat důvěru konkrétně pro povzbuzení klientů k předložení jejich pověřovacích informací. Ve druhém případě by bylo možné přístup použít k tomu, aby se klientovi umožnilo požadovat od serveru pověřovací informace dříve, než tomuto serveru předloží jakékoliv své pověřovací informace. Avšak tím by bylo pro server pověřovací informace před pověřovacích informací. Tak nemožné požadovat klientovy předložením svých vlastních by se totiž mohla vytvořit (2782725_CZ.doc) ··*·«· · »9 · · « • ♦ β ♦ · · · 4 I «· ·· ·♦··*·
- 7 - . : ’ σ i : : : :
···· ♦· ··» «· ·· ·«· cyklická závislost přivádějící vyjednávání do slepé uličky, protože v tomto modelu ovládá všechny klientovy pověřovací informace stejný postup, a tedy jakýkoliv následný požadavek serveru by vedl na stejný požadavek klienta.
Podstata vynálezu
Podle prvního hlediska vynález zajišťuje zařízení pro zpracování dat pro použití v sítích klient/server, kde klientské zařízení pro zpracování dat posílá požadavek na zpracováni dat na serverové zařízení pro zpracování dat a serverové zařízení pro zpracování dat provádí zpracování dat na základě požadavku a vrací odpověď klientské zařízení pro zpracování dat, přičemž zařízení pro zpracování dat obsahuje: paměťové prostředky pro ukládání více pověřovacích informací své strany; prostředky pro příjem prvního požadavku na pověřovací informace od zařízení pro zpracování dat opačné strany, přičemž pověřovací informace požadované prvním požadavkem na pověřovací informace jsou pověřovacími informacemi své strany uložené v paměťových prostředcích, které vyhovují prvnímu logickému výrazu dodanému s prvním požadavkem na pověřovací informace; a prostředky pro posílání druhého požadavku na pověřovací informace zařízeni pro zpracování dat druhé strany, který závisí na obsahu prvního požadavku na pověřovací informace, přičemž pověřovací informace požadované druhým požadavkem na pověřovací informace jsou pověřovacími informacemi druhé strany, které vyhovují druhému logickému výrazu dodanému s druhým požadavkem na pověřovací informace.
Podle druhého hlediska vynález zajišťuje způsob provozování zařízení pro zpracování dat podle prvního (2782725_CZ.doc) • 4 · · • · ♦ ·« · e * · # 9
9 9999*9 W 4 4 4 ««*«»«
9999 99 999 ·» ·· 990 hlediska.
Podle třetího hlediska zajišťuje vynález produkt počítačového programu uložený na počítačem čitelném úložném médiu pro provádění kroků způsobu podle druhého hlediska, když běží na počítači.
Podle čtvrtého hlediska vynález zajišťuje signál počítačových dat namodulovaný na nosnou vlnu, přičemž signál má programové prvky pro instruování počítače pro provádění kroků způsobu podle druhého hlediska.
Vynález tedy rozšiřuje přístup k pověřovacím informacím podle stavu techniky, aby podpořil posloupnost vzájemně závislých požadavků na předložení pověřovacích informací. Aby se umožnila posloupnost vzájemně závislých požadavků na předložení pověřovacích informací, musí být různé pověřovací informace ovládány různými postupy. Požadavek na pověřovací informace, který přijme klient od serveru, není na jednotlivé pověřovací informace, dokonce ani na zvláštní kombinace pověřovacích informací. Místo toho je na doplňkové pověřovací informace, které vyhovují logickému výrazu.
V tomto vynálezu se příchozí požadavek na pověřovací informace logicky zkombinuje s pověřovacími informacemi klientem právě drženými, společně s postupem pro řízení přístupu spojeným s každou z těchto pověřovacích informací, aby se odvodil nový požadavek na pověřovací informace opačné strany. Tento vynález tudíž obsahuje jakékoliv odvození respondentova požadavku na pověřovací informace od místních postupů pro přístup k pověřovacím informacím a příchozího požadavku na pověřovací informace, kromě případu, kde je respondentův požadavek nezávislý na příchozím požadavku.
V tomto druhém, výjimečném případě, není možné předkládání (2782725_CZ.doc) ···»·« 4 · · ♦ · * •4 4 4 4 4 4 4 4 4· · · · · 4 4 « · ♦ 444«·· 4
4·· · 4 4 444
4444 ·« ·«♦ ·* »· 444 posloupnosti inkrementálních pověřovacích informací kvůli cyklickým závislostem, jak bylo popsáno výše.
Žádné dřívější řešení výslovně nedoporučuje použití pověřovacích informací jako základu pro ovládání předkládání pověřovacích informací. Neexistuje žádná zmínka o tomto problému vzájemných závislostí mezi pověřovacími informacemi a potřebou požadovat různé postupy pro přístup k pověřovacím informacím pro různé postupy, aby se zamezilo určité slepé uličce. To jsou hlediska automatizace ustavování důvěry mezi neznámými, kteří drží své pověřovací informace, které byly v minulosti překontrolovány, v soukromí.
Také neexistuje žádná předchozí zmínka o dynamicky se vytvářejících požadavcích na pověřovací informace během ustavování důvěry. Dřívější řešení vybírala obsah požadavku na pověřovací informace z předtím existujících postupů.
Vynález zajišťuje úplnou automatizaci vyjednávání o důvěře mezi neznámými zařízeními pro zpracování dat, které si chrání své pověřovací informace. Ihned lze použít jednoduché vyjednávači strategie. Lze vzít v úvahu také promyšlenější techniky, které vyvažují záležitosti úspěšného vyjednávání a vyhýbají se nepozorným předložením informaci o držených pověřovacích informacích.
Důležitou výhodou zajištěnou vynálezem je, že umožňuje, aby se důvěra ustavila automaticky, i když zúčastněné strany vyžadují nějaké znalosti o svých protějšcích před tím, než jim předloží své pověřovací informace. V dřívějších řešeních měl každý účastník v rámci každého vyjednávání pouze jednu příležitost předložit pověřovací informace a jeden účastník musel být první. Oproti předchozím řešením vynález (2782725_CZ.doc) nevyžaduje, pověřovaci aby každý účastník informace všechny jednání předložil své vědomostí o druhém účastníkovi.
naj ednou
Aby získal bez jakýchkoliv vysoce citlivou službu, může klient být nucen předložit vysoce citlivou pověřovaci informaci, kterou předkládá pouze po nejprve získal mírněji citlivou serveru. Proto může i server požadovat pověřovaci tom, co informaci nějakou méně citlivou pověřovaci informaci.
Vynález umožňuje vyjednávat v libovolně dlouhé posloupnosti závislých výměn pověřovacích informací. V některých případech může taková posloupnost umožnit vyjednat vyšší stupeň důvěry, než může jedna výměna. To činí nové řešení potenciálně velmi důležitým v souvislosti s e-business (tj . elektronické obchodování) mezi neznámými účastníky, kde automatická obchodní jednáni budou vyžadovat vysoký stupeň důvěry, který účastníci ujednají v dobré víře a naloží s předloženými informacemi odpovídajícím způsobem.
Vynález zajišťuje základ pro automatické vyjednávání o předložení inkrementálních pověřovacích informací. Dělá to spojováním každé držené pověřovaci informace své strany s postupem přístupu založeným na pověřovacích informacích druhé strany a pro logickou kombinaci tohoto postupu zajištěním příchozího požadavku na pověřovaci informace, aby se odvodily vyjednávači odpovědi.
Přehled obrázků na výkresech
Vynález bude blíže vysvětlen prostřednictvím konkrétních příkladů provedení znázorněných na výkresech, na kterých představuje (2782725_CZ.doc)
- 11 obr. 1 blokové schéma ukazující softwarové komponenty podle upřednostňovaného provedení tohoto vynálezu;
obr. 2 vývojový diagram ukazující kroky zpracovávání prováděné místní stranou podle upřednostňovaného provedení tohoto vynálezu; a obr. 3 je příklad časovacího diagramu ukazujícího posloupnost požadavků a odpovědí podle upřednostňovaného provedení tohoto vynálezu.
Příklady provedení vynálezu
V upřednostňovaném provedení vynálezu přes datovou komunikační síť vzájemně komunikuje více jednotek zpracovávajících data. Na obr. 1 je ukázána místní strana 10, jak komunikuje sítí (není ukázána) s druhou stranou 11, přičemž obě tyto strany jsou jednotkami zpracovávajícími data v upřednostňovaném provedení (v jiném provedení mohou být oddělenými procesy běžícími na stejné jednotce zpracovávající data). Podle druhého přístupu dosavadního stavu techniky [Ching a kol., Winslett a kol.] výše je jednotka zpracovávající data (tj. vyjednávání) zastoupena ve vyjednáváních bezpečnostním agentem 101, jak je znázorněno na obr. 1.
Každý účastník vyjednávání může dostat požadavek na pověřovací informace (příchozí požadavek 21 na pověřovací informace, obr. 1). (Každý požadavek na pověřovací informace má tvar vzorce pro pověřovací informace jako ve druhém přístupu dosavadního stavu techniky probraném výše.) Tento popsaného účastník o důvěře (2782725_CZ.doc) požadavek je pro předložení pověřovacich informaci místní strany druhé straně. Účelem tohoto předložení může být buď odblokovat službu, nebo odblokovat předložení pověřovacich informací druhé strany potřebných pro další vyjednávání o důvěře. Okamžitým problémem pro pokračování ve vyjednávání je určit, zda má místní strana 10 dostatečnou důvěru ve druhou stranu 11, aby jí předložila požadované pověřovací informace, a pokud ne, aby vytvořila požadavek na pověřovací informace druhé strany (odchozí požadavek 22 na pověřovací informace), které by tuto důvěru nastolily.
Jak je znázorněno na obr. 1, každá strana spojuje postup 102 přístupu k pověřovacím informacím s každou ze svých pověřovacich informací 103. Tento postup přístupu označuje pověřovací informace druhé strany, které by odblokovaly předložení pověřovacich informací místní strany. Když se přijme požadavek 21 na pověřovací informace, bezpečnostní agent 101 určí, která činnost je vhodná. Toto určení je popsáno v následujících odstavcích v souvislosti s blokovým schématem na obr. las kroky (31-37) vývojového diagramu zobrazeného na obr. 2.
Akce bezpečnostního agenta začínají krokem 31, když od druhé strany získá požadavek 21 na pověřovací informace ve tvaru logického výrazu. Pokud místní strana v kroku 32 zjistí, že nevlastní pověřovací informace, které by požadavku vyhovovaly (a pokud se požaduje nějaký druh odpovědi, jako je tomu když bezpečnostní agent náleží serveru), může se v kroku 33 poslat odmítnutí. Jinak musí bezpečnostní agent v kroku 34 určit, zda již byla ve druhou stranu nastolena dostatečná důvěra, která by opravňovala poskytnutí kombinace pověřovacich informací, které splňují požadavku. Konkrétně pověřovací informace 23 druhé strany, (2782725_CZ.doc) «·*««· · ·· ·· · ♦ · · Φ · · · 9 · · · ·· ··♦··· »9 ······ 9
9 9 9 9 9 9 · ·
9999 99 999 9· 9· ··· které doprovázejí požadavek 21 nebo které jsou již uschované 104 lokálně, mohou splňovat postupy 102 přístupu, které ovládají místní pověřovací informace 103, které zase splňují příchozí požadavek 21. V tomto případě se kombinace místních pověřovacích informací tímto způsobem odblokovaných a splňujících příchozí straně 11, příchozí požadavek požadavek 21 jak je ukázáno v kroku požadavek přijat jako místní stranou, může zopakovat informacemi, nyní vzbudí požadavku.
kroku 35 ve spojení za předpokladu, že důvěru, mohou poslat
35. Když byl odpověď na se předchozí druhé stáváj ící předchozí požadavek s posílanými pověřovacími tyto pověřovací informace aby se odblokovalo splnění předchozího
Na druhou stranu krok 34 může rozhodnout, že pro místní stranu přístupné pověřovací informace druhé strany (23 a/nebo 104) nedostačují k odblokování kombinace místní stranou vlastněných pověřovacích informací 103, které splňují příchozí požadavek 21. V tomto případě v kroku 36 bezpečnostní agent 101 odvodí odchozí požadavek 22 na další pověřovací informace od druhé strany 11 logickou kombinací příchozího požadavku na pověřovací informace 21 s postupem 102 přístupu k pověřovacím informacím místní strany. Tyto pověřovací informace druhé strany jsou požadovány pro účely odblokování pověřovacích informací místní strany, které si vyžádala druhá strana. Abychom se tedy vyhnuli zbytečnému požadování pověřovacích informací, odvozovací proces zjednoduší požadavek tím, že vezme v úvahu, které z požadovaných pověřovacích informací místní strana právě vlastní 103, a navíc nežádá o další pověřovací informace druhé strany pro odblokování pověřovacích informací místní strany, které jsou již odblokovány nashromážděnými 104 a/nebo příchozími 23 pověřovacími informacemi druhé strany.
(2782725_CZ.doc)
V kroku 37, když bezpečnostní na další pověřovací informace odblokovaly pověřovací informace v tom samém okamžiku vybrat informace místní strany, požadavek aby se může si
Například může poskytnout uvedené v příchozím
Zatímco riskuje informací, místní strany informace.
pověřovacích strategie může zvýšit agent 101 pošle druhé strany, místní strany, poskytnout některé pověřovací které jsou již odblokovány.
informace již některé pověřovací požadavku 21 na poskytnutí rozhodnutí toto naděj i a rychlost, pověřovací zbytečných vyjednávači se kterou to zvýšením pravděpodobnosti toho, vyjednávání uspěje. Dělá že druhá strana ihned poskytne pověřovací informace, o které se žádá, a snížením pravděpodobnosti, že druhá strana vyvodí závěr, že existuje cyklická vzájemná závislost v rámci zkombinovaných postupů přístupu k pověřovacím informacím obou stran a odstoupí tedy od vyjednávání.
Jak ukazuje obr. 1, když je místní strana serverem a druhá strana klientem, obsah zprávy přicházející serveru od klienta může obsahovat požadavek 24 na službu. Takový požadavek na službu je běžně první zprávou ve vyjednávání o předložení pověřovacích informací mezi klientem a serverem. Na základě přijetí požadavku 24 na službu bezpečnostní agent 101 serveru použije postup ovládání služeb (není ukázáno na obr. 1), aby se rozhodl, zda pověřovací informace 23 druhé strany, které doprovázejí požadavek, dostačují pro splnění postupu ovládání služeb (to se také vyskytuje ve druhém přístupu dosavadního stavu techniky probraném výše). Přestože jsou některé servery bez stavů a neponechávají si tedy pověřovací informace klienta po každém požadavku klienta, jiné si mohou, jako klienti, schovávat pověřovací informace druhé strany 104. Takové (2782725_CZ.doc) • · *··· • · servery využívají uschované pověřovací informace druhé strany 104, stejně jako ty 23, které doprovázejí požadavek, který se má pokusit splnit jejich postupy ovládání služeb. Ať už se uschované pověřovací informace 104 druhé strany použijí, nebo ne, když je splněn postup ovládání služeb, služba se schválí 25. Jinak bezpečnostní agent 101 vrátí postup ovládání služeb ve tvaru odchozího požadavku na pověřovací informace 22 . O předložení pověřovacích informací se potom vyjednává mezi klientem a serverem, a pokud je úspěšné, klient může opakovat požadavek na službu s přiloženými dostačujícími pověřovacími informacemi, aby se služba schválila. Příkladem je výměna, jak ji ukazuje obr. 3.
Na obr. 3 v kole 1 klient posílá na stranu serveru požadavek na konkrétní službu, ve které žádá, aby server jménem klienta vykonal určitou zpracovávací úlohu (např. přečetl přístup do databáze). K požadavku nejsou přiloženy žádné pověřovací informace, protože se předpokládá, že klient nezná postup pověřovacích informací ovládající tuto službu. V kole 2 bezpečnostní agent serveru posílá bezpečnostnímu agentu klienta postup ovládání služeb, který uvědomuje bezpečnostního agenta o jeho možnostech ohledně pověřovacích informací, které se mají předložit pro vytvoření dostatečné důvěry na straně bezpečnostního agenta serveru, aby se požadovaná služba provedla. Tento postup ustaví požadavek na pověřovací informace a tím způsobem se s ním zachází, když je přijat bezpečnostním agentem klienta v kole 3.· Bezpečnostní agent klienta odpoví podle kroků popsaných výše v souvislosti s vývojovým diagramem na obr. 2.
To znamená, že bezpečnostní agent klienta přijme (2782725_CZ.doc)
94« · 4 9 9 99 4
4444 9999
9 9 9 9 9 99
9 9 9 9 9 9 9 99
9 9 9 9 9 9 99
9999 44 444 44 99999 požadavek na pověřovací informace (krok 31) (aby se schválila služba požadovaná v kole 1). Určí, že klient vlastní alespoň jednu kombinaci pověřovacích informací, které splňují požadavek (krok 32) . Určí, že nemá na místě dostupné dostatečné pověřovací informace serveru ke splnění postupů ovládání přístupu ustavených pověřovacích informací z jakékoliv z těchto splňujících kombinací (krok 34) . Odvodí si tedy nový požadavek (krok 36) navržený k odblokování takové vyhovující kombinace svých vlastních pověřovacích informací, které by zase mohly odblokovat požadovanou službu. Nakonec pošle serveru požadavek bez jakýchkoliv přiložených pověřovacích informací. (V obměně příkladu může klient v tomto bodě přiložit k odchozímu požadavku nějaké pověřovací informace požadované serverem v kole 2, například kdyby jim je jejich postupy řízení přístupu umožňovaly předložit bez předchozí znalosti serveru.)
Kolo 4 začíná, když bezpečnostní agent serveru přijme požadavek na pověřovací informace poslaný klientem na konci kola 2· Tento požadavek se znovu zpracuje, jak bylo výše popsáno v souvislosti s vývojovým diagramem na obr. 2. Bezpečnostní agent serveru rozhodne, že má pověřovací informace, které splňují požadavek bezpečnostního agenta klienta (krok 32.) , a že nejsou pro předložení bezpečnostnímu agentovi klienta všechny odblokovány (krok 34) (bezpečnostní agent serveru zatím nedostal žádné pověřovací informace od bezpečnostního agenta klienta). Odvodí si požadavek (krok 36) na pověřovací informace klienta, které mají odblokovat pověřovací informace požadované bezpečnostním agentem klienta, a pošle ji (krok 37) bezpečnostnímu agentovi klienta společně s nějakými pověřovacími informacemi, které bezpečnostní agent klienta požadoval a jejichž postup řízení přístupu umožňuje jejich předložení, (2782725_CZ.doc) • 4 4 4 Φ 4 · Φ · φ 4 ·· ······ » · Φ Φ Φ φ 4 4 Φ Φ
4 4 444 444
4444 φφ φφφ ΦΦ φφ φφφ bez dřívějšího prohlédnutí jakýchkoli pověřovacích informací klienta.
Kolo 5 začíná, když bezpečnostní agent klienta přijme požadavek a pověřovací informace poslané bezpečnostním agentem serverů na konci kola 4. Bezpečnostní agent klienta rozhodne, že má pověřovací informace, které splňují požadavek (krok 32), ale že není složena žádná splňující kombinace z pověřovacích informací, jejichž postupy řízení přístupu jsou odblokovány dosud přijatými pověřovacími informacemi serveru (krok 34) · Ve snaze odblokovat více ze svých pověřovacích informací poté bezpečnostní agent klienta odvodí následujícím způsobem nový požadavek na pověřovací informace serveru (krok 36) . Pozmění příchozí požadavek na pověřovací informace tím, že nahradí odkazy na pověřovací informace, které nevlastní, konstantou nepravda (falše) . Potom nahradí každý zbývající výskyt pověřovací informace, kterou nevlastní, postupem pro přístup k pověřovacím informacím. Výsledný vzorec, jako uvedené postupy pro přístup, je vyjádřen ve smyslu pověřovacích informací druhé strany. Dále se spojí s požadavkem na pověřovací informace poslaným předtím klientem serveru na konci kola 3_, který stále ještě nemusí být uspokojen pověřovacími informacemi přijatými ze serveru. Bezpečnostní agent zjednoduší výsledné spojení, aby se zamezilo zbytečnému požadavku na pověřovací informace. Zjednodušení se provede tak, že se ze vzorce vypustí každý výskyt pověřovací informace, kterou již bezpečnostní agent klienta obdržel a která splňuje omezující podmínky atributů vyjádřené ve vzorci. Výsledný vzorec je zjednodušen tím, že zachází s vypuštěnými pověřovacími informacemi jako s konstantou pravda (true) a odpovídajícím způsobem zjednoduší logické spoje. (Výskyt pravdy v logickém součinu se prostě vypustí; prázdný logický součin se nahradí (2782725_CZ.doc) pravdou; logický součet obsahující pravdu se nahradí pravdou.) Nakonec bezpečnostní agent klienta pošle vzorec, který odvodil a tímto způsobem zjednodušil, a pošle také jakékoliv pověřovaci informace požadované v příchozím požadavku, jejichž postupy řízení přístupu jsou odblokovány pověřovacími informacemi serveru přijatými na začátku tohoto kola.
Kolo J5 začíná, když bezpečnostní agent serveru přijme požadavek a pověřovaci informace jemu zaslané bezpečnostním agentem klienta na konci kola 5. Bezpečnostní agent serveru se rozhodne, že má pověřovaci informace splňující požadavek (krok 32), ale že všechny nejsou odblokované (krok 36) , více méně stejným způsobem znázorněným na straně klienta v kole 5.. Rozhodující rozdíl v odvození na straně serveru od toho na straně klienta tkví v tom, že ve vyjednávači strategii znázorněné v tomto příkladu server znovu nepoužívá své předchozí požadavky na pověřovaci informace klienta.
Kolo 7 začíná, když bezpečnostní agent klienta přijme požadavek na pověřovaci informace zaslané bezpečnostním agentem serveru na konci kola 6. Bezpečnostní agent serveru určí, že má alespoň jednu kombinaci pověřovacích informací, která splňuje požadavek (krok 32.) . Klient nyní přijal dostačující pověřovaci informace serveru, aby takovou kombinaci pověřovacích informací odblokoval (krok 34). Takže jednu takovou kombinaci serveru na konci kola 7 pošle společně se stejným požadavkem na pověřovaci informace, který serveru poslal na konci kola EL
Kolo 8. začíná, když bezpečnostní agent serveru přijme opakovaný požadavek a pověřovaci informace jemu zaslané klientem na konci kola 7. Bezpečnostní agent serveru určí, (2782725_CZ.doc) ·· ···« · ·· ·· • · · ···· ··· • ♦ ♦ · · · ··· ···· ·· ··· ·· ·· ··· že má pověřovací informace, které splňují požadavek (krok 32) , a že jsou odblokovány (krok 34), protože jejich postupy řízení přístupu jsou splněny pověřovacími informacemi klienta zaslanými klientem na konci kola 7. Potom pošle tyto pověřovací informace klientovi.
Kolo 9_ začíná, když bezpečnostní agent klienta dostane pověřovací informace zaslané serverem na konci kola 8_. Tyto pověřovací informace společně s pověřovacími informacemi přijatými bezpečnostním agentem klienta na začátku kol 5. a 7. a od té doby uschovanými bezpečnostním agentem klienta splňují postupy řízení přístupu pověřovacích informací klienta, které splňují postup ovládání služby přijatý bezpečnostním agentem klienta v kole 3_. Bezpečnostní agent klienta poté pošle kombinaci odblokovaných pověřovacích informací, které společně splňují postup ovládání služeb. Také opakuje původní požadavek na službu.
Kolo 10 začíná, když bezpečnostní agent serveru přijme požadavek na službu a pověřovací informace zaslané klientem na konci kola 9_. Tyto pověřovací informace splňují postup ovládání služeb, takže služba se ověří, provede a její výsledek vrátí. Je klientem přijat v kole 11, které náš příklad uzavírá.
Příklad vyjednávání
Zde uvedený příklad znázorňuje jedenáct kroků hypotetického vyjednávání schematicky zobrazeného na obr. 3.
Má znázorňovat zpracování vzorců, jak je předepsáno upřednostňovaným provedením tohoto vynálezu. Vzorce jsou vyjádřeny neformálně. Příklad je pro pouze ilustrační a není určen k tomu, aby adekvátním způsobem vyznačoval jakékoliv skutečné vyjednávání, pověřovací informace nebo postupy.
(2782725_CZ.doc) ·· Φ··«
Φ Φ Φ
·« • · φφ φ φ φ*
Hypotetické pověřovací informace
Každá položka pověřovacích informaci začíná zkratkou použitou pro tuto pověřovací informaci ve zbytku příkladu.
Pověřovací informace o bezpečnostních technikách držené jak klientem, tak serverem
Předpokládáme, že specialisté na standardy bezpečnostních technik vydávají pověřovací informace o bezpečnostních technikách na entity, jejichž bezpečnostní infrastrukturu předepisují. Zaměření může být použito třetími stranami k odhadnutí pravděpodobnosti, že entitě poskytnuté informace budou nedopatřením touto entitou poskytnuty. Aby se hodnocené entitě umožnilo předvést, že splnily požadavky určitého stupně, zatímco uchovávají v soukromí stupně, které nesplnily, vydá se pro každý stupeň oddělená pověřovací informace s atributem nazvaným prošel, který má hodnotu pravda, když jsou pro tento stupeň splněny požadavky, a jinak nepravda.
V našem příkladu jsou čtyři stupně bezpečnostních technik, nízký, střední, vysoký a velmi vysoký. Nejvyšší stupeň splněný serverem je vysoký a nejvyšší stupeň splněný klientem je střední. Každá entita si chrání pověřovací informace, které má pro stupně, kterým nevyhovuje. Pokud by pověřovací informace pro stupně, kterými prošla, nebyly také chráněny, rozdíl v ochraně by ozřejmil, kterým stupňům nevyhovují. Takže se chrání pověřovací informace pro všechny stupně (kromě nejvyššího), ať už jimi vlastník prošel, nebo ne.
Velmi vysoký stupeň bezpečnostních technik. Vysoká (2782725_CZ.doc)
| • | ·· 0 | |||||
| w « | ♦ · « | • | • | 0 | 00 | |
| • | « | • 0 | 0 | • | 4 | 0 |
| • | ||||||
| • | • » | • · | • | • | 0 | • |
| ·* s· | 9·· 99 | 0« | • •t |
citlivost.
Vysoký stupeň bezpečnostních technik. Střední citlivost.
Střední stupeň bezpečnostních technik. Nízká citlivost.
Nízký stupeň bezpečnostních technik. Necitlivý.
Pověřovací informace klienta
Smlouva Dodací smlouvy. Vydané stranou očekávající dodávku zboží. Vysoce citlivá. Je třeba se ujistit, že informace neprosáknou ke konkurenci.
Kredit Akreditiv. Vydaný věřitelem vlastníkovi. Střední-vysoká citlivost.
Překladiště Skladní smlouva v začátečním překladišti. Vydaná správou překladiště. Stření citlivost. Je potřeba zamezit rozšíření mezi konkurencí.
S-stvrzenka Stvrzenka dřívější přepravy. Vydaná dopravcem přepravujícím v minulosti zboží. Klient nemá v tomto příkladě žádné stvrzenky dřívější přepravy.
Účet Zařízený účet u serveru/dopravce. Vydaný dopravcem. V tomto případě nemá klient zařízený účet u serveru/dopravce.
B-org Pověřovací informace členství v obchodní organizaci. Vydaná obchodní organizací, jako je Mezinárodní obchodní komora. Necitlivá.
Pověřovací informace serveru
Stvrzenka Stvrzenka dřívější dodávky. Vydaná vlastníkem zboží převáženého v minulosti. Necitlivá.
Obligace Potvrzení obligace. Vydané agenturou pro obligace. Necitlivé.
Ref Dobrozdání od výrobce. Vydané výrobcem, který chce (2782725_CZ.doc) • ·
- 22 “ »*♦·*·♦···· • · · · ·« ··· ·· ·· ·*· doporučit dopravce na základě předchozí obchodní zkušenosti. Nízká citlivost. Server má v tomto příkladě nejméně dvě od různých výrobců.
B-org Pověřovací informace členství v obchodní organizaci. Vydaná obchodní organizací, jako je Mezinárodní obchodní komora. Necitlivá.
Hypotetické postupy
Postup, který ovládá pověřovací informace X serveru nebo klienta, se označuje Xkiient, respektive Xserver· Postupy zde vyjádřené nejsou úplné. Konkrétně nevyjadřují požadavky na podporu pověřovacích informací, které jsou zásadní. Přestože nejsou zcela úplné nebo reálné, věty uvedené kde znázorňují použití omezujících podmínek na atributy pověřovacích informací. Například postup řízení přístupu klienta pro své pověřovací informace o dodacích smlouvách vyžaduje dobrozdání ode dvou různých vystavovatelů pověřovacích informací.
Postupy ovládání pověřovacích informací klienta smlouvakiient = vysoká AND Refx AND Ref2 AND (obligace OR (stvrzenka! AND stvrzenka2) ) , kde vysoká.prošlo = pravda AND Refx. vystavovatel Ψ Ref2 .vystavovatel AND stvrzenkai.vystavovatel * stvrzenka2. vystavovatel kreditkiient = střední AND Refí AND Ref2, kde střední. prošel = pravda AND Refí. vystavovatel Ψ Ref2. vystavovatel překladištěkiient = střední AND (obligace OR (stvrzenkai AND stvrzenka2) ) , kde střední.prošel = pravda AND stvrzenkai.vystavovatel stvrzenka2.vystavovatel velmi vysokýkiient = vysoký AND B-Org, kde vysoký, prošel = pravda vysokýkiient = střední AND B-org, kde střední .prošel = pravda středníkiient = nízký AND B-org, kde nízký.prošel = pravda (2782725_CZ.doc)
nizkýkiient = nevyžadují se žádné pověřovací informace
Postupy ovládání pověřovacích informací serveru stvrzenkaserver = nevyžadují se žádné pověřovací informace obligaceserver = nevyžadují se žádné pověřovací informace Refserver = nízký, kde nízký.prošel = pravda velmi vysoký3erver = vysoký AND B-org, kde vysoký, prošel = pravda vysokýserver = střední AND B-org, kde střední.prošel = pravda středníserver = nízký AND B-org, kde nízký.prošel = pravda nízkýserver = nevyžadují se žádné pověřovací informace
Postup ovládání služby serveru pro naplánování přepravy účet OR (obligace AND ( (s-stvrzenkai AND s-stvrzenka2) OR smlouva) AND kredit), kde s-stvrzenkai .vystavovatel Ψ s-stvrzenka2 .vystavovatel
Kroky vyjednávání
Příkladem je úspěšné vyjednávání. Požadavky na pověřovací informace se posílají na konci kol 2 až 7. Pověřovací informace klienta požadované serverem na konci kola 2 jsou potřeba ke schváleni služby. Zbytek vyjednávání slouží k navázání dostatečné důvěry pro klienta, aby tyto pověřovací informace serveru předložil. Pověřovací informace požadované v kolech 3 až 7 jsou potřeba, aby se odblokoval přístup k pověřovacím informacím, které jsou naopak potřeba pro úspěšné vyjednávání.
V každém kole, ve kterém strana přijme požadavek na pověřovací informace, vlastní strana pověřovací informace, které splňují požadavek a krok 32 na obr. 2 je úspěšný. Na konci každého takového kola určující bezpečnostní agent pošle druhé straně všechny pověřovací informace požadované (2782725_CZ.doc) v příchozím požadavku, jehož postupy přístupu jsou odblokovány pověřovacími informacemi druhé strany, které jsou dostupné místní straně. Ty jsou označeny níže jako odblokované požadované pověřovací informace. Ve vyjednávači strategii znázorněné tímto příkladem klientův bezpečnostní agent uschovává a opakuje předchozí požadavky, zatímco server nikoliv.
Kolo 1 -- Klient posílá požadavek na službu:
Naplánování data přepravy
Kolo 2 -- Server přijímá požadavek, vrací postup ovládání služby
Server potřebuje získat důvěru, že klient je opravdu na trhu s přepravními službami a může za ně zaplatit. Pošle postup ovládání služby pro naplánování přepravy ukázaný výše.
Kolo 3 -- Klient přijímá požadavek na pověřovací informace pro schválení služby
Pověřovací informace serveru dostupné místní straně: žádné Odblokované žádané pověřovací informace: žádné (krok 34 selhává)
Příchozí požadavek, zjednodušený vypuštěním pověřovacích informací, které klient nevlastní:
překladiště AND smlouva AND kredit
Tento vzorec, kde každá pověřovací informace je nahrazena svým (ozávorkovaným) postupem přístupu:
[střední AND (obligace OR (stvrzenkai AND stvrzenka2) ) , kde střední.prošel = pravda AND stvrzenkai .vystavovatel stvrzenka2. vystavovatel] AND [vysoká AND Refí AND Ref2 AND (obligace OR (stvrzenkai AND stvrzenka2) ) , kde vysoký.prošel = pravda AND
Refí. vystavovatel A Ref2 .vystavovatel AND (2782725_CZ.doc) • · · · stvrzenkai.vystavovatel stvrzenka2.vystavovatel] AND [střední AND Refí AND Ref2, kde střední.prošel = pravda AND Refí.vystavovatel Ψ Ref2.vystavovatel]
Vzorec, zjednodušený, jak se pošle serveru coby požadavek na pověřovací informace na konci kroku 3:
vysoký AND Refí AND Ref2 AND (obligace OR (stvrzenkai AND stvrzenka2) ) AND střední, kde vysoký.prošel = pravda AND Refí. vystavovatel * Ref2 .vystavovatel AND stvrzenkai. vystavovatel s tvr z enka2 .vystavovatel AND střední.prošel = pravda
Kolo 4 -- Služba přijme požadavek na pověřovací informace
Pověřovací informace klienta dostupné místní straně: žádné Odblokované požadované pověřovací informace: obligace (krok 34 selhává)
Příchozí požadavek, s každou pověřovací informací nahrazenou svým (ozávorkovaným) postupem přístupu:
[střední AND B-org, kde stření.prošel = pravda] AND [nízká, kde nízká.prošel = pravda] AND [nízká, kde nízká.prošel = pravda] AND ([nevyžadují se žádné pověřovací informace] OR ([nevyžadují se žádné pověřovací informace] AND [nevyžadují se žádné pověřovací informace])} AND [nízká AND B-org, kde nízká.prošel = pravda]
Tento vzorec, zjednodušený, jak se pošle klientovi na konci kola 4 :
střední AND nízký AND B-org, kde střední.prošel = pravda AND nízký.prošel = pravda
Krok 5 -- Klient přijímá požadavek na pověřovací informace a jednu pověřovací informaci serveru
Pověřovací informace serveru dostupné místní straně:
(2782725_CZ.doc) obligace
Odblokované požadované pověřovaci informace: nízká, B-org (krok 34 selhává)
Příchozí požadavek, s každou pověřovaci informací nahrazenou svým (ozávorkovaným) postupem přístupu:
[nízká AND B-org, kde nízká.prošel=pravda] AND [nevyžadují se žádné pověřovaci informace] AND [nevyžadují se žádné pověřovaci informace]
Tento vzorec, spojený s požadavkem zaslaným serveru na konci kola 3 :
{(nízká AND B-org, kde nízká.prošel = pravda) AND [nevyžadují se žádné pověřovaci informace] AND [nevyžadují se žádné pověřovaci informace]} AND [vysoká AND Refí AND Ref2 AND (obligace OR (stvrzenkai AND stvrzenka2) ) AND střední, kde vysoký.prošel=pravda AND
Ref i.vystavovatel
Ref 2.vystavovatel
AND stvrzenkai .vystavovatel Φ stvrzenka2. vystavovatel
AND střední.prošel = pravda]
Požadavek, zjednodušený vypuštěním pověřovacích informací serveru, které jsou dostupné místní straně, jak se pošlou serveru na konci kola 5:
nízký AND B-org AND vysoký AND Refí AND Ref2 AND střední, kde nízký.prošel=pravda AND vysoký.prošel = pravda AND Ref i .vystavovatel Ψ Ref 2 .vystavovatel AND střední.prošel = pravda
Kolo 6 -- Server přijímá požadavek na pověřovaci informace a dvě pověřovaci informace klienta
Pověřovaci informace klienta dostupné místní straně: nízká,
B-org (2782725_CZ.doc)
Odblokované požadované pověřovací informace: nízká, B-org, střední (krok 34 selhává)
Příchozí požadavek, s každou pověřovací informací nahrazenou svým (ozávorkovaným) postupem přístupu:
[nevyžadují se žádné pověřovací informace] AND [nevyžadují se žádné pověřovací informace] AND [střední AND B-org, kde střední.prošel=pravda] AND [nízká, kde nízká.prošel = pravda] AND [nízká, kde nízká.prošel = pravda] AND [nízká AND B-org, kde nízká.prošel = pravda]
Požadavek, zjednodušený vypuštěním pověřovacich informací klienta, které jsou dostupné místní straně, jak se pošlou klientovi na konci kola 6:
střední, kde střední.prošel = pravda
Kolo 7 -- klient přijímá požadavek na pověřovací informace a tři pověřovací informace serveru
Pověřovací informace serveru dostupné místní straně: obligace (uschovaná od kola 5), nízká, B-org, střední
Odblokované požadované pověřovací informace: střední (krok 34 uspěje)
Požadavek, jak se poslal serveru na konci kola 5 (viz krok 35) :
nízký AND B-org AND vysoký AND Refí AND Ref2 AND střední, kde nízký.prošel=pravda AND vysoký.prošel = pravda AND Re fi. vystavovatel Ψ Ref2 .vystavovatel AND střední. prošel = pravda
Požadavek, zjednodušený vypuštěním pověřovacich informací serveru, které jsou dostupné místní straně, jak se pošlou (2782725_CZ.doc) serveru na konci kola 7:
vysoká AND Refí AND Ref2, kde vysoký, prošel = pravda AND Refí. vystavovatel Ref2 . vystavovatel
Kolo 8 -- Server přijímá požadavek na pověřovací informace a jednu pověřovací informaci klienta
Pověřovací informace klienta dostupné místní straně: nízká,
B-org (obě uschované od kola 6), střední
Odblokované požadované pověřovací informace: vysoká, Refí,
Ref2 (krok 34 uspěje, pověřovací informace se pošlou v kroku
35)
Kolo 9 -- Klient přijímá tři pověřovací informace serveru, které dokončí odblokování pověřovacích informací klienta, které schválí službu
Jelikož není přijat žádný další požadavek na pověřovací informace, odpovídajícím požadavkem (krok 31) se ještě jednou stává postup ovládání služby přijatý na začátku kola 3 .
Pověřovací informace serveru dostupné místní straně: obligace (přijatá v kole 5) , nízká, B-org, střední (přijaté v kole 7), vysoká, Refí, Ref2 (přijaté v kole 9)
Odblokované požadované pověřovací informace: překladiště, smlouva, kredit (krok 34 uspěje)
Požadavek na službu, naplánování dat přepravy, poprvé poslaný v kroku 1, je nyní zopakován s přiloženými požadovanými pověřovacími informacemi.
(2782725_CZ.doc) <* · · · · · « · •··· · ·
Kolo 10 -- Server přijímá požadavek na službu a tři přiložené pověřovací informace, schvaluje službu
Server potvrzuje, že přiložené pověřovací informace splňují postup ovládání služby a schvaluje požadovanou službu. Výsledek této služby je vrácen na konci kola 10.
Kolo 11 -- Klient přijímá službu, kterou požadoval
Claims (14)
- PATENTOVÉ NÁROKYJUDr. Petr Kalenský advokát 120 00 Praha 2, Hálkova 21 . Zařízeni pro zpracování dat pro použití v síti klient/server, kde klientské zařízení pro zpracování dat pošle požadavek na zpracování dat serverovému zařízení pro zpracování dat a serverové zařízení pro zpracování dat provede zpracování dat na základě požadavku a vrátí odpověď klientskému zařízení pro zpracování dat, vyznačující se tím, že zařízení pro zpracování dat obsahuje:paměťové prostředky pro uložení více pověřovacích informací místní strany;prostředky pro přijetí prvního požadavku na pověřovací informace od zařízení pro zpracování dat druhé strany, přičemž požadované pověřovací informace požadované prvním požadavkem na pověřovací informace jsou pověřovacími informacemi místní strany uložené v paměťových prostředcích, které splňují první logický výraz dodaný s prvním požadavkem na pověřovací informace; a prostředky pro zaslání zařízení pro zpracování dat druhé strany druhého požadavku na pověřovací informace, který je závislý na obsahu prvního požadavku na pověřovací informace, přičemž pověřovací informace požadované druhým požadavkem na pověřovací informace jsou pověřovacími informacemi druhé strany, které splňují druhý logický výraz dodaný s druhým požadavkem na pověřovací informace.
- 2. Zařízení podle nároku 1, vyznačující se tím, že paměťové prostředky také ukládají více postupů přístupu k pověřovacím informacím, přičemž každý postup ovládá přístup k odpovídajícím pověřovacím informacím místní strany na základě pověřovacích informací druhé strany.27 82725 (2782725_CZ.doc) ····«* · · · ·♦ · ♦ · · · · · ♦ · » · * ·· 9 9 9 9·· “31” · · · ****** ·**· ·· «·· ·· ·· ·♦♦
- 3. Zařízeni podle nároku 2, vyznačující se tím, že dále obsahuje:rozhodovací prostředky pro rozhodnuti toho, zda první logický výraz dodaný s prvním požadavkem na pověřovací informace je splněn kombinací pověřovacích informací místní strany uložených v paměťových prostředcích, a když je učiněno rozhodnutí, že je první logický výraz dodaný s prvním požadavkem na pověřovací informace splněn kombinací pověřovacích informací místní strany uložených v paměťových prostředcích, přičemž rozhodne, zda postupy pro přístup k pověřovacím informacím uložené v paměťových prostředcích a ovládající kombinaci pověřovacích informací místní strany, které splňují první logický výraz dodaný s prvním požadavkem na pověřovací informace, jsou splněny pověřovacími informacemi druhé strany, které jsou lokálně dostupné;odesílací prostředky pro posílání kombinace pověřovacích informací místní strany zařízení pro zpracování dat druhé strany, když rozhodovací prostředky rozhodnou, že postupy pro přístup k pověřovacím informacím jsou splněny pověřovacími informacemi druhé strany, které jsou dostupné lokálně; a prostředky pro logické kombinování, když rozhodovací prostředky rozhodnou, že postupy pro přístup k pověřovacím informacím nejsou splněny pověřovacími informacemi, které jsou dostupné lokálně, logicky kombinující (a) přijatý první požadavek na pověřovací informace, (b) uložené pověřovací informace druhé strany a (c) uložené postupy pro přístup k pověřovacím informacím, aby se odvodil druhý logický výraz ve druhém požadavku na pověřovací informace druhé strany, které společně s dostupnými pověřovacími informacemi druhé strany místní straně, splňují místní postupy pro přístup k pověřovacím informacím, které ovládají kombinaci (2782725_CZ.doc) ♦ · · · · ·- 32 pověřovacích informací místní strany, které splňují první logický výraz dodaný s prvním požadavkem na pověřovací informace místní strany.
- 4. Zařízení pro zpracování dat podle nároku 1, vyznačující se tím, že zařízení pro zpracování dat druhé strany je klientské zařízení pro zpracování dat.
- 5. Zařízení pro zpracování dat podle nároku 1, vyznačující se tím, že zařízení pro zpracování dat je serverové zařízení pro zpracování dat.
- 6. Zařízení pro zpracování dat podle nároku 1, vyznačující se tím, že pověřovací informace druhé strany jsou zachycovány do mezipaměti typu cache do lokálního úložiště.
- 7. Zařízení vyznačující s základě zjištění, zprávu sdělující toto druhé strany.pro zpracování dat podle nároku tím, že rozhodovací prostředky neexistuje, pošlou pro zpracování dat3, na že taková kombinace zjištění zařízení
- 8. Zařízení pro zpracování dat podle nároku 1, vyznačující se tím, že síť klient/server je internet.
- 9. Způsob provozování zařízení pro zpracování dat pro použití v síti klient/server, kde klientské zařízení pro zpracování dat pošle požadavek na zpracování dat serverovému zařízení pro zpracování dat a serverové zařízení pro zpracování dat provede zpracování dat na základě požadavku a vrátí odpověď klientskému zařízení pro zpracování dat, přičemž zařízení pro zpracování dat obsahuje paměťové (2782725_CZ.doc) prostředky pro uložení více pověřovacích informací místní strany, vyznačující se tím, že způsob obsahuje kroky:přijetí prvního požadavku na pověřovaci informace od zařízení pro zpracování dat druhé strany, přičemž pověřovaci informace informace požadované prvním požadavkem jsou pověřovacími informacemi na pověřovaci místní strany paměťových logický výraz dodaný informace; a uložené v prostředcích, které s prvním požadavkem splňují první na pověřovaci poslání zařízení pro zpracování dat druhé strany druhého požadavku na pověřovaci informace, který závisí na obsahu prvního požadavku na pověřovaci informace, přičemž pověřovaci informace požadované druhým požadavkem na pověřovaci informace jsou pověřovacími informacemi druhé strany, které splňují druhý logický výraz dodaný s druhým požadavkem na pověřovaci informace.
- 10. Způsob podle nároku 9, vyznačující se tím, že paměťové prostředky ukládají také více postupů pro přístup k pověřovacím informacím, přičemž každý postup ovládá přístup k odpovídajícím pověřovacím informacím místní strany na základě pověřovacích informací druhé strany.
- 11. Způsob podle nároku 10, vyznačující se tím, že dále obsahuje kroky:rozhodnutí, zda je první logický výraz dodaný s prvním požadavkem na pověřovaci informace splněn kombinací pověřovacích informací místní strany uložených v paměťových prostředcích, a když je učiněno rozhodnutí, že je první logický výraz dodaný s prvním požadavkem na pověřovaci informace splněn kombinací pověřovacích informací místní strany uložených v paměťových prostředcích, rozhodnutí, zda (2782725_CZ.doc) postupy pro přístup k pověřovacím informacím uložené v paměťových prostředcích a ovládající kombinaci pověřovacích informací místní strany, které splňují první logický výraz dodaný s prvním požadavkem na pověřovací informace, jsou splněny pověřovacími informacemi druhé strany, které jsou dostupné lokálně;poslání kombinace pověřovacích informací místní strany zařízení pro zpracování dat druhé strany, když krok rozhodnutí rozhodne, že postupy pro přístup k pověřovacím informacím jsou splněny pověřovacími informacemi druhé strany, které jsou dostupné lokálně; a když krok rozhodnutí rozhodne, že postupy pro přístup k pověřovacím informacím, které jsou dostupné lokálně, logické zkombinování (a) přijatého prvního požadavku na pověřovací informace, (b) uložených pověřovacích informací druhé strany a (c) uložených postupů pro přístup k pověřovacím informacím, aby se odvodil druhý logický výraz ve druhém požadavku na pověřovací informace druhé strany, které, společně s pověřovacími informacemi druhé strany dostupnými lokálně, splňují místní postupy pro přístup k pověřovacím informacím, které ovládají kombinaci pověřovacích informací místní strany, které splňují první logický výraz dodaný
s prvním požadavkem na pověřovací informace místní strany. 12 . Způsob podle nároku 9, vyzn ačiij ící s e tím, že zařízení pro zpracování dat druhé strany je klientské zařízení pro zpracování dat. 13 . Způsob podle nároku 9, vyznačující s e tím, že zařízení pro zpracování dat druhé strany je serverové zařízení pro zpracování dat. 14. Způsob podle nároku 9, vyznačující s e tím, (2782725_CZ.doc) ···« ·· že pověřovací informace druhé strany se uschovají v lokálním úložišti. - 15. Způsob podle nároku 9, vyznačující se tím, že síť klient/server je internet.
- 16. Produkt počítačového programu uložený na počítačem čitelném úložném médiu pro, když běží na zařízení pro zpracování dat, instruování zařízení pro zpracování dat k provádění kroků způsobu podle nároku 9.
- 17. Datový signál produktu počítačového programu ztělesněný do nosné vlny, když běží na zařízení pro zpracování dat, pro instruování zařízení pro zpracování dat k provádění kroků způsobu podle nároku 9.
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US09/260,249 US6349338B1 (en) | 1999-03-02 | 1999-03-02 | Trust negotiation in a client/server data processing network using automatic incremental credential disclosure |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CZ20013150A3 true CZ20013150A3 (cs) | 2002-01-16 |
Family
ID=22988414
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CZ20013150A CZ20013150A3 (cs) | 1999-03-02 | 2000-02-24 | Oboustranné ověřování zpráv v datové síti pomocí automatického inkrementálního předkládání pověřovacích informací |
Country Status (15)
| Country | Link |
|---|---|
| US (1) | US6349338B1 (cs) |
| EP (1) | EP1157321B8 (cs) |
| JP (1) | JP3701871B2 (cs) |
| KR (1) | KR100431566B1 (cs) |
| CN (1) | CN1211719C (cs) |
| AT (1) | ATE438892T1 (cs) |
| AU (1) | AU2813000A (cs) |
| CA (1) | CA2363721C (cs) |
| CZ (1) | CZ20013150A3 (cs) |
| DE (1) | DE60042682D1 (cs) |
| HU (1) | HUP0105181A2 (cs) |
| IL (2) | IL144902A0 (cs) |
| PL (1) | PL350242A1 (cs) |
| TW (1) | TW453074B (cs) |
| WO (1) | WO2000052557A1 (cs) |
Families Citing this family (33)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6775783B1 (en) | 1999-08-13 | 2004-08-10 | Cisco Technology, Inc. | Client security for networked applications |
| US7215637B1 (en) * | 2000-04-17 | 2007-05-08 | Juniper Networks, Inc. | Systems and methods for processing packets |
| US7688727B1 (en) | 2000-04-17 | 2010-03-30 | Juniper Networks, Inc. | Filtering and route lookup in a switching device |
| US7174454B2 (en) | 2002-11-19 | 2007-02-06 | America Online, Inc. | System and method for establishing historical usage-based hardware trust |
| EP1285317A1 (en) * | 2000-05-19 | 2003-02-26 | Netscape Communications | Adaptive multi-tier authentication system |
| US8095624B2 (en) | 2000-12-28 | 2012-01-10 | CenterBeam Inc. | Architecture for serving and managing independent access devices |
| TW541467B (en) * | 2001-05-11 | 2003-07-11 | Mitac Int Corp | Knowledge management system and method |
| FR2826811B1 (fr) * | 2001-06-27 | 2003-11-07 | France Telecom | Procede d'authentification cryptographique |
| JP2003223394A (ja) * | 2001-11-20 | 2003-08-08 | Matsushita Electric Ind Co Ltd | 交渉機能を有する装置と合意形成システム |
| US7571467B1 (en) | 2002-02-26 | 2009-08-04 | Microsoft Corporation | System and method to package security credentials for later use |
| US7603452B1 (en) | 2002-03-26 | 2009-10-13 | Symantec Corporation | Networked computer environment assurance system and method |
| US7496952B2 (en) * | 2002-03-28 | 2009-02-24 | International Business Machines Corporation | Methods for authenticating a user's credentials against multiple sets of credentials |
| US8473355B2 (en) * | 2002-12-06 | 2013-06-25 | Facebook, Inc. | System and method for electronic wallet conversion |
| US20040128542A1 (en) * | 2002-12-31 | 2004-07-01 | International Business Machines Corporation | Method and system for native authentication protocols in a heterogeneous federated environment |
| GB2398712B (en) * | 2003-01-31 | 2006-06-28 | Hewlett Packard Development Co | Privacy management of personal data |
| US7703128B2 (en) | 2003-02-13 | 2010-04-20 | Microsoft Corporation | Digital identity management |
| US7644280B2 (en) * | 2004-04-08 | 2010-01-05 | International Business Machines Corporation | Method and system for linking certificates to signed files |
| US7984488B2 (en) | 2004-04-09 | 2011-07-19 | Microsoft Corporation | Credential roaming in electronic computing systems |
| JP2005316890A (ja) * | 2004-04-30 | 2005-11-10 | Sony Corp | プログラム、コンピュータ、データ処理方法、通信システムおよびその方法 |
| JP4265479B2 (ja) * | 2004-05-26 | 2009-05-20 | ソニー株式会社 | 通信システム |
| US7581248B2 (en) * | 2004-06-28 | 2009-08-25 | International Business Machines Corporation | Federated identity brokering |
| US7647626B2 (en) * | 2004-12-08 | 2010-01-12 | International Business Machines Corporation | Method for establishing a trusted relationship between a data server and a middleware server |
| US7568039B2 (en) * | 2004-12-27 | 2009-07-28 | International Business Machines Corporation | Method for providing and utilizing a network trusted context |
| US7844816B2 (en) * | 2005-06-08 | 2010-11-30 | International Business Machines Corporation | Relying party trust anchor based public key technology framework |
| CN101102180B (zh) * | 2006-07-03 | 2010-08-25 | 联想(北京)有限公司 | 基于硬件安全单元的***间绑定及平台完整性验证方法 |
| US8327142B2 (en) | 2006-09-27 | 2012-12-04 | Secureauth Corporation | System and method for facilitating secure online transactions |
| JP5186648B2 (ja) * | 2006-09-27 | 2013-04-17 | セキュアオース コーポレイション | 安全なオンライン取引を容易にするシステム及び方法 |
| US8108910B2 (en) * | 2007-10-16 | 2012-01-31 | International Business Machines Corporation | Methods and apparatus for adaptively determining trust in client-server environments |
| US8788809B2 (en) * | 2009-04-27 | 2014-07-22 | Qualcomm Incorporated | Method and apparatus to create a secure web-browsing environment with privilege signing |
| US8881258B2 (en) | 2011-08-24 | 2014-11-04 | Mcafee, Inc. | System, method, and computer program for preventing infections from spreading in a network environment using dynamic application of a firewall policy |
| CN115907763A (zh) | 2013-07-26 | 2023-04-04 | 维萨国际服务协会 | 向消费者提供支付凭证 |
| US9426183B2 (en) * | 2013-07-28 | 2016-08-23 | Acceptto Corporation | Authentication policy orchestration for a user device |
| US11438325B2 (en) | 2020-02-28 | 2022-09-06 | EMC IP Holding Company LLC | Trust establishment by escalation |
Family Cites Families (17)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5560008A (en) * | 1989-05-15 | 1996-09-24 | International Business Machines Corporation | Remote authentication and authorization in a distributed data processing system |
| DE69029759T2 (de) * | 1989-05-15 | 1997-07-17 | Ibm | Flexible Schnittstelle für Beglaubigungsdienste in einem verteilten Datenverarbeitungssystem |
| EP0440158B1 (en) * | 1990-01-30 | 1997-09-10 | Kabushiki Kaisha Toshiba | Mutual authentication system |
| GB9104909D0 (en) * | 1991-03-08 | 1991-04-24 | Int Computers Ltd | Access control in a distributed computer system |
| US5148479A (en) | 1991-03-20 | 1992-09-15 | International Business Machines Corp. | Authentication protocols in communication networks |
| US5235642A (en) * | 1992-07-21 | 1993-08-10 | Digital Equipment Corporation | Access control subsystem and method for distributed computer system using locally cached authentication credentials |
| US5586260A (en) * | 1993-02-12 | 1996-12-17 | Digital Equipment Corporation | Method and apparatus for authenticating a client to a server in computer systems which support different security mechanisms |
| US5299263A (en) * | 1993-03-04 | 1994-03-29 | Bell Communications Research, Inc. | Two-way public key authentication and key agreement for low-cost terminals |
| DE4317380C1 (de) | 1993-05-25 | 1994-08-18 | Siemens Ag | Verfahren zur Authentifikation zwischen zwei elektronischen Einrichtungen |
| US5434918A (en) * | 1993-12-14 | 1995-07-18 | Hughes Aircraft Company | Method for providing mutual authentication of a user and a server on a network |
| US6067582A (en) | 1996-08-13 | 2000-05-23 | Angel Secure Networks, Inc. | System for installing information related to a software application to a remote computer over a network |
| US5826021A (en) * | 1996-09-17 | 1998-10-20 | Sun Microsystems, Inc. | Disconnected write authorization in a client/server computing system |
| US5845068A (en) * | 1996-12-18 | 1998-12-01 | Sun Microsystems, Inc. | Multilevel security port methods, apparatuses, and computer program products |
| US5995624A (en) * | 1997-03-10 | 1999-11-30 | The Pacid Group | Bilateral authentication and information encryption token system and method |
| JP4268690B2 (ja) * | 1997-03-26 | 2009-05-27 | ソニー株式会社 | 認証システムおよび方法、並びに認証方法 |
| US6199113B1 (en) * | 1998-04-15 | 2001-03-06 | Sun Microsystems, Inc. | Apparatus and method for providing trusted network security |
| US6195682B1 (en) * | 1998-10-27 | 2001-02-27 | International Business Machines Corporation | Concurrent server and method of operation having client-server affinity using exchanged client and server keys |
-
1999
- 1999-03-02 US US09/260,249 patent/US6349338B1/en not_active Expired - Lifetime
-
2000
- 2000-02-16 TW TW089102611A patent/TW453074B/zh not_active IP Right Cessation
- 2000-02-24 HU HU0105181A patent/HUP0105181A2/hu unknown
- 2000-02-24 WO PCT/GB2000/000661 patent/WO2000052557A1/en active IP Right Grant
- 2000-02-24 KR KR10-2001-7011148A patent/KR100431566B1/ko active IP Right Grant
- 2000-02-24 AT AT00906466T patent/ATE438892T1/de not_active IP Right Cessation
- 2000-02-24 CA CA002363721A patent/CA2363721C/en not_active Expired - Lifetime
- 2000-02-24 IL IL14490200A patent/IL144902A0/xx active IP Right Grant
- 2000-02-24 DE DE60042682T patent/DE60042682D1/de not_active Expired - Lifetime
- 2000-02-24 JP JP2000602912A patent/JP3701871B2/ja not_active Expired - Lifetime
- 2000-02-24 PL PL00350242A patent/PL350242A1/xx not_active Application Discontinuation
- 2000-02-24 CN CNB00807108XA patent/CN1211719C/zh not_active Expired - Lifetime
- 2000-02-24 EP EP00906466A patent/EP1157321B8/en not_active Expired - Lifetime
- 2000-02-24 AU AU28130/00A patent/AU2813000A/en not_active Abandoned
- 2000-02-24 CZ CZ20013150A patent/CZ20013150A3/cs unknown
-
2001
- 2001-08-14 IL IL144902A patent/IL144902A/en not_active IP Right Cessation
Also Published As
| Publication number | Publication date |
|---|---|
| PL350242A1 (en) | 2002-12-02 |
| CA2363721C (en) | 2004-11-30 |
| US6349338B1 (en) | 2002-02-19 |
| AU2813000A (en) | 2000-09-21 |
| TW453074B (en) | 2001-09-01 |
| CN1211719C (zh) | 2005-07-20 |
| KR20010108294A (ko) | 2001-12-07 |
| KR100431566B1 (ko) | 2004-05-17 |
| EP1157321B8 (en) | 2009-09-16 |
| DE60042682D1 (de) | 2009-09-17 |
| EP1157321B1 (en) | 2009-08-05 |
| JP3701871B2 (ja) | 2005-10-05 |
| EP1157321A1 (en) | 2001-11-28 |
| JP2002538701A (ja) | 2002-11-12 |
| ATE438892T1 (de) | 2009-08-15 |
| CA2363721A1 (en) | 2000-09-08 |
| WO2000052557A1 (en) | 2000-09-08 |
| HUP0105181A2 (en) | 2002-04-29 |
| CN1349625A (zh) | 2002-05-15 |
| IL144902A (en) | 2006-04-10 |
| IL144902A0 (en) | 2002-06-30 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CZ20013150A3 (cs) | Oboustranné ověřování zpráv v datové síti pomocí automatického inkrementálního předkládání pověřovacích informací | |
| US11962577B2 (en) | Resource transfer setup and verification | |
| US8117105B2 (en) | Systems and methods for facilitating electronic securities transactions | |
| US7610391B2 (en) | User-centric consent management system and method | |
| US8185932B2 (en) | System and method for user-centric authorization to access user-specific information | |
| US20100235882A1 (en) | Method and system for using tokens in a transaction handling system | |
| US20100235284A1 (en) | Method and systems for generating and using tokens in a transaction handling system | |
| US20030135752A1 (en) | Multiple trust modes for handling data | |
| Ratnasingam | The importance of technology trust in web services security | |
| US20100235286A1 (en) | Method and system for generating tokens in a transaction handling system | |
| US7664688B2 (en) | Managing information in a multi-hub system for collaborative planning and supply chain management | |
| US20060059004A1 (en) | Apparatus and method for managing account information | |
| CA2343805C (en) | Method of improving security in electronic transactions | |
| US20090077641A1 (en) | Collaborative processing using inference logic | |
| US20190158418A1 (en) | Exchange hosting server | |
| Bertino et al. | Trust-: An XML Framework for Trust Negotiations | |
| US20020184100A1 (en) | Casual access application with context sensitive pin authentication | |
| CN115470289A (zh) | 风险数据处理方法、装置和*** | |
| MXPA01008795A (en) | Mutual authentication in a data network using automatic incremental credential disclosure | |
| Bertino et al. | A Comprehensive XML Based Approach to Trust Negotiations | |
| AU2005297338A1 (en) | Collaborative processing using inference logic |