Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [higgins-dev] FW: [osis-general] Alternative to html object type="application/x-informationCard" ? 
IE triggers its extension mechanism based on HTML <OBJECT type="...">. Not 
sure the <LINK> proposal could be handled in the same way.

Another issue may become, in the future, the "requiredClaims" syntax, 
where the currently embraced set of space separated URL strings (denoting 
identity attributes) could
be replaced with a more elaborate claims language (as proposed in 
WS-Federation 1.2 drafts). Such claims can be embedded as CDATA into 
<PARAM value="...">, but more
elegant ways may exist?

Kind regards,
Carl




"Paul Trevithick" <paul@xxxxxxxxxxxxxxxxx> 
Sent by: higgins-dev-bounces@xxxxxxxxxxx
05/21/2008 08:04 AM
Please respond to
"Higgins \(Trust Framework\) Project developer discussions" 
<higgins-dev@xxxxxxxxxxx>


To
"'Higgins \(Trust Framework\) Project developer discussions'" 
<higgins-dev@xxxxxxxxxxx>
cc

Subject
[higgins-dev] FW: [osis-general] Alternative to html    object 
type="application/x-informationCard" ?






I'm reposting Axel's message to see if perhaps it will solicit more 
reaction
on the higgins-dev list...

-----Original Message-----
From: osis-general-bounces@xxxxxxxxxxx
[mailto:osis-general-bounces@xxxxxxxxxxx] On Behalf Of Nennker, Axel
Sent: Friday, May 02, 2008 4:38 AM
To: osis-general@xxxxxxxxxxx
Subject: [osis-general] Alternative to html object
type="application/x-informationCard" ?

Hi,

Several times while I struggled with the openinfocard id selector to be
triggered by the various methods of doing this I thought that the HTML
object element of mime type application/x-informationcard might not have
been the best choice to do the browser integration.

Here my current favorite alternative to HTML-object: Let us use
http://developer.mozilla.org/en/docs/HTML:Element:link
http://www.w3.org/TR/html4/struct/links.html#h-12.3

Example1: (inline policy)

<HEAD>
<TITLE>Example Relying Party</TITLE>
<LINK title="This is the policy related to claims"
      type="application/x-informationcard"
      rel="claims-policy"
      content="<claims-policy>
<param name="post-token-to"
value="https://xmldap.org/relyingparty/infocard"/>
<param name="privacyUrl"
value="https://xmldap.org/relyingparty/?privacy.txt"/>
<param name="requiredClaims"
value="
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/privatepersonal
identifier http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"/>
<param name="optionalClaims"
value="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/streetaddress
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/locality
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/stateorprovince
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/postalcode
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/country
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/homephone
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/otherphone
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/mobilephone
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/dateofbirth
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/gender"/>
<param name="privacyVersion" value="1"/>
<param name="tokenType" value="urn:oasis:names:tc:SAML:1.0:assertion"/>
<claims-policy>">

Or alternatively: Expressing token requirements as per ISIP 1.0 section 
3.1
Example2: (referenced policy)
<HEAD>
<TITLE>Example Relying Party</TITLE>
<LINK title="This is the policy related to claims"
      type="application/xml+ws-security-policy"
      rel="claims-policy"
      href="https://xmldap.org/relyingparty/issuerpolicy.xml";>

This alternative uses the same method to get the issuerpolicy from the RP 
as
the issuerpolicy param of the object would use.
We need a way to express where the security token should be send... (Put
this in the policy like an IdP endpoint?)

----------------

So how does this help with triggering the id selector? It does not. The
above is a new way to express the RP requirements.
The triggering of the id selector is achieved through a rendering element 
in
the browser that the user clicks.
An example could be the Higgins mouse next to the address bar. Or an
Infocard Icon next to the address bar.
There a multiple examples of Firefox extensions that handle 'link
rel="next"' etc.

----------------

The above does not address why HTML-object is problematic, but anybody who
has implemented an id selector knows.
My major arguments:
- The Mozilla foundation thinks that HTML-objects are for rendering media
content only. So object in the HTML head section are not visible and
therefore not rendered.
- HTML-objects are expected to be handled by browser plugins, which are
platform dependent.
- You need javascript kungfu to suppress the "additional plugins are 
needed"
message.
- objects are designed to be rendered by the browser but the 
informationcard
thingy is not rendered.

-----

Using LINK does not stretch the HTML-browser-rendering like HTML-object
does.
If a browser does not know the "rel" part it is simply ignored.

-----

I would like to start a discussion about this. Please join in.

In the past I was concerned whether changing from HTML-object to HTML-LINK
would hinder the acceptance/adaption of information cards.
I think that it would not. I think "LINK" is a better way to express the
requirements of the RP and "better" than HTML-object.
And a build-in infocard icon to trigger the id selector is good.

Have fun
Axel

Ps: Multiple informationcard-objects on one page are easier to express 
with
HTML-object, but
- we did not address this in the interop yet
- This was suggested to handle alternate issuers (VISA, Mastercard,...) 
but
I think this should be expressed in the policy instead.






















Axel Nennker
T-Systems Enterprise Services GmbH
Goslarer Ufer 35
D-10589 Berlin
Email axel.nennker@xxxxxxxxxxxxx
Tel. +49 (030) 3497 -3256
Fax +49 (030) 3497 -3257


T-Systems Enterprise Services GmbH
Aufsichtsrat: René Obermann (Vorsitzender)
Executive Committee: Reinhard Clemens (Vorsitzender)*, Helmut Binder, 
Albert
Henn, Olaf Heyden*, Katrin Horstmann, Joachim Langmack*, Wilfried Peters*,
Dr. Stefan Schloter, Zvezdana Seeger*
Handelsregister: Amtsgericht Frankfurt am Main HRB 55933
Sitz der Gesellschaft: Frankfurt am Main
WEEE-Reg.-Nr. DE87523644
*Geschäftsführer gem. § 35 GmbHG

Notice: This transmittal and/or attachments may be privileged or
confidential. If you are not the intended recipient, you are hereby 
notified
that you have received this transmittal in error; any review, 
dissemination,
or copying is strictly prohibited. If you received this transmittal in
error, please notify us immediately by reply and immediately delete this
message and all its attachments. Thank you.
T-Systems - Business flexibility

_______________________________________________
osis-general mailing list
osis-general@xxxxxxxxxxx
http://mailman.netmesh.us/mailman/listinfo/osis-general

_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/higgins-dev

Back to the top