ABCDEFHIJLMNOPQRSTUVWXYZ
1
2
PATTERNSModified ITI-18d) SOAP Request of Authorization Unmodified ITI-18 Request (modified ITI-18 Response) Policy Manager stores Autorization Tickets
(unmodified ITI-18 and ITI-43 and new Transaction between Rep and Policy Manager)		l) encode the whole Token into the docID (token by value, maybe compressed...) m) The Policy Manager notifies the Repository that an authorization is released for a document stored into it. (not a query but a push)DefinitionDiscussion
3
a) Retrieval Token within a SOAP headerb) Retrieval Token within Body Response (new element)c) Retrieval Token within Additional Metadatae) Retrieval Token within a SOAP headerf) Retrieval Token within Body Response (new element)g) Retrieval Token within Additional Metadatah) cache by docIdi) encode the tokenReference into the docUniqueId returned by the Query
4
Pattern DescriptionUsing a modified ITI-18 Request, the XDS Document Consumer actor obtains Retrieval Tokens back from the registry within an addtional SOAP headerUsing a modified ITI-18 Request, the XDS Document Consumer actor obtains Retrieval Tokens back from the registry within a new body element Using a modified ITI-18 Request, the XDS Document Consumer actor obtains Retrieval Tokens within additional Metadata A new standalone transaction for the XDS Document Consumer that allows the Request of authorizations using SOAP WS Without changing the ITI-18 Request, retrieval tokens are released to the consumer within an addtional SOAP header Without changing the ITI-18 Request, retrieval tokens are released to the consumer within a new body elementWithout changing the ITI-18 Request, retrieval tokens are released to the consumer as additional metadataTransactions supported by the XDS Document Consumer are unchanged. The authorization for the retrieval of documents is directly verified by the XDS Document Repository asking the Policy Manager. The Document Repository shall support an additional transaction. Authorizations are cached by document ID within the Policy Manager actor. Transactions supported by the XDS Document Consumer are unchanged. The authorization for the retrieval of documents is directly verified by the XDS Document Repository asking the Policy Manager The Document Repository shall support an additional transaction. The Atuhorization token refernce is encoded as part of the DocumentID returned by the Query Response. The XDS Document Repository shall verify retrieve the full Authoritzation using this token reference. Transactions supported by the XDS Document Consumer and by the XDS Document Repository are unchanged. The authorization for the retrieval of documents is full encoded (compressed within the document ID). For each documentEntry discovered by queries the Policy Manager actor will send an authorization token to the XDS Document Repository that stores the document
5
Criteria
Wt. (1-3)†
‡‡‡‡‡‡
6
Standards/Pattern Development Criteria
WS-Security+SAML 2.0 (Ass)
custom + SAML 2.0 (Ass)
XDS + ?XDS + SAML 2.0
WS-Security+SAML 2.0 (Ass)
custom + SAML 2.0 (Ass)
XDS + ?
WS-Trust + SAML 2.0 (Ass + Prot)
WS-Trust + SAML 2.0 (Ass + Prot)XDS + SAML (Ass)
WS-BaseNotification , SAML 2.0
7
Maturity1-1-1-11-1-101111Is the standard (or the coupled use of different standards) normative?
8
Market Penetration1-1-1-11-1-101110Is the standard (and the pattern proposed for the use of that standard) widely adopted by industry?
9
Activity1-1-1-11-1-111111Is there sufficient activity by the SDO on the standard? Is the standard still actively being supported/
developed?
10
IP / Legal111111111111Is the candidate standard's license free from provisions which would prevent it's use within the profile?
11
Use-case Needs
12
Transactional Efficiency1111-1111-1-11-1The efficiency is the main goal of the proposal. Number of Transaction (and transaction/communication delays), Implementation Costs, Cost of ownership...
13
deployment10-1001-111111How the solution proposed support the transition from one environment to the Environemnt that supports the new functionalities (co-existence of old and news systems). (1 low costs -1 High costs)
14
Coupling of systems11110111-1-11-1Minimize coupling. Need for direct comunications between Rep and Reg to evaluate access rights (1 integration NOT needed -1 integration needed )
15
changes in transaction for the XDS Document Consumer 1-1-1-1-10001111Need for UPGRADE of domain's consumers (1 changes not needed , -1 many changes needed)… this involves costs and time…
16
change in behavior required 10-1-1000-11111A high behavior needed on the Document Consumer site can be a problem (-1 high behavior needed , +1 Low behavior needed)
17
18
Technical Criteria
19
Additional Computational Load 11111111-10-11Massage Payload, Computational Resources needed to sign tickets, resources needed for the storing of tickets
20
Security Issues introduced100000001111Security Issues introduced by the pattern (-1 high relevance of the issue)
21
Message Size 111-1111-11011
22
flexibility1-1-1-11-1-1-10-1-11Solution that can be applied to different use-cases in future
23
Weighted Scores0-2-352036598
24
NOTE: Technical feasibility is still an issue for this solution.
25
† Weights are:
1 = Not important,
2 = Moderately Important,
3 = Very Important
26
‡ Evaluations:
1 = Yes : The candidate addresses the criteria
0 = Unclear : The candidate may provide a way of addressing the criteria, but it is unclear
-1 = No : The candidate does not address the criteria
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100