Presentation of Claims

As I wrote in a previous post I added a demo geopriv STS to the openinfocard code repository which manages civic addresses. As claim's identifiers I used URLs inspired by rfc4119 e.g.
urn:ietf:params:xml:ns:pidf:geopriv10:civicLoc:A6 (street name without number)
You might have seen here and in the image above that the presentation of these claims in the id selectors GUI is, well, not satisfying.
The displaytag and the claim's description from the information card are not very helpful in the case of civic addresses. Maybe the rendering information should be attached to the DisplayToken instead of to each DisplayClaim.
The format of an rfc4119 civic address was designed to work around the globe which makes it a little bit difficult to handle.

Which choices do I have as an id selctor and/or STS?

• I could use a (deep versus flat) claim: ietf:civicaddress which has an XML civicaddress as it's value.
  Current id selectors would display this in one line... Not pretty
  Future id selectors would know that the value of the claim ietf:civicaddress is not a plain text but XML which should be rendered as a user expects it.


• I could enhance the id selector to render claims of this kind appropriately.
  I would have to do this for every new set of claims. -> not elegant


• The STS could include an XSLT (XML geopriv civicaddress to HTML) script to render the claims in the id selector.
  Maybe the RP does know how to render the claims better?
  Maybe the user knows how to render the claims better?


• The RP could render the claims while I chose which card to present.
  This is not desirable, because the RP would learn about all my cards.


• The id selector could render the claims using CSS/XSLT provided by the RP
  Do I trust the RP this much?


• The id selector could render the claims using it's own (provided by the user?) CSS/XSLT script.
  Only a few users will be able to understand this.

More questions than answers. Sorry.

The flat versus deep claim's value needs more discussion too. Maybe it is another side of the same coin? Not.
Mark Wahl has put this far better than me in this short post. His posts are here and here.