[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
AW: [higgins-dev] FW: [osis-general] Alternative to htmlobject type="application/x-informationCard" ?
|
Hi all,
Paul says that _I_ as the author have to post the message to higgins-dev so that it falls under the Eclipse License.
So here it is again.
enjoy,
Axel
I guess that I need a tutorial about licenses...
-----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
