For discussion:

1. Removing the static resource-udi element [1]

After discussion with John Bradley and Markus Sabadello I now see that it
would be better to eliminate the static resource-udi element from the r-card
card XML. Why? (a)  It is redundant with the resource-udi claim (b) worse
than redundant, it is static whereas the claim value is dynamic thus it may
have an inconsistent value compared to the dynamic value  (c) by removing it
an r-card becomes really just a ³profile² of a managed card‹the card .crd
file contains no extra XML elements when compared to a regular m-card (just
a rather special claim type URI). The disadvantage is that now any client
(including a selector) must authenticate to the STS and request the
resource-udi in order to learn its value. If it had to do this every time,
performance could suffer. Nevertheless, we¹re going to assume that some
clever caching can address this drawback and thus make this change.

2. [Optionally] allowing the resource-udi's value to be an XRD

After discussions with John, Markus and Drummond Reed we now believe that
the value should either be a UDI [as it is today] or [and this is the new
option] an "inline" XRD document. The option to inline the XRD allows what
John calls ³private discovery² option in addition to the current [public]
discovery options used during UDI resolution. This addresses some privacy
leakage inherent in public discovery.

Note that there is an interop issue with CardSpace 1.0 & 1.5 in that these
versions (unlike the forthcoming "Geneva" (2.0) release) are badly behaved
WRT XML that they don't understand; namely, that these versions don't
preserve it on export. But the interop situation with this proposed change
is no worse than it was WRT to the previous approach.

3. Renaming "resource-udi" to "resource-udr" at the ICF

Since per #2 above the value isn't necessarily a UDI (it might be a UDI or
an inlined-XRD), we should rename this claim if possible. This should be
okay with the ICF since (a) it was only voted "provisional" [to capture its
³experimental² status] and (b) only one project is yet using this claim
type. 

[1] http://wiki.eclipse.org/R-Card#XML_Format

--Paul
_______________________________________________
higgins-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/higgins-dev

Reply via email to