You loose that trust of issuance if you don't have that come from an IdP, also there may be cases where you want this to be updated/renewed thus I don't think its a 1 time shot only, also the RP or any other party may want to validate the token. Anthony Nadalin | Work 512.838.0085 | Cell 512.289.4122 |------------> | From: | |------------> >------------------------------------------------------------------------------------------------------------------------------------------| |Tom Carroll <[email protected]> | >------------------------------------------------------------------------------------------------------------------------------------------| |------------> | To: | |------------> >------------------------------------------------------------------------------------------------------------------------------------------| |"Higgins (Trust Framework) Project developer discussions" <[email protected]> | >------------------------------------------------------------------------------------------------------------------------------------------| |------------> | Date: | |------------> >------------------------------------------------------------------------------------------------------------------------------------------| |05/11/2009 04:59 PM | >------------------------------------------------------------------------------------------------------------------------------------------| |------------> | Subject: | |------------> >------------------------------------------------------------------------------------------------------------------------------------------| |[higgins-dev] RE: Three proposed changes Higgins R-Cards | >------------------------------------------------------------------------------------------------------------------------------------------| #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
<<inline: graycol.gif>>
<<inline: ecblank.gif>>
_______________________________________________ higgins-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/higgins-dev
