But if it is not a claim, how can a relying party request it? And we're saying that r-cards are a superset of m-cards, so they need an STS anyway, no?
Markus On Mon, May 11, 2009 at 5:57 PM, Tom Carroll <[email protected]> wrote: > #1 implies that r-cards require a WS-Trust STS. This seems to be a high > bar for adoption, particularly when there are several use cases where the > resource UDI is effectively static, and would only ever need to be > retrieved from the STS once. Standing up and maintaining an STS to issue a > one-time claim seems like overkill. m-cards already specify their STS > endpoints; it seems reasonable to treat the r-card endpoint in the same > way, no? > > > > > > *From:* [email protected] [mailto: > [email protected]] *On Behalf Of *Paul Trevithick > *Sent:* Sunday, May 10, 2009 9:12 PM > *To:* higgins-dev > *Subject:* [higgins-dev] Three proposed changes Higgins R-Cards > > > > 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 > >
_______________________________________________ higgins-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/higgins-dev
