Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: AW: [higgins-dev] FW: [osis-general] Alternative tohtml object type="application/x-informationCard" ?

Axel,
you're right: HTML <LINK> also supports attribute "type", i.e. MIME types 
can be used. 

Inconvenience of <LINK> is that these must be grouped with <HEAD>.

How about using the "requiredClaims" <PARAM> to embed a reference (e.g. 
link)  to policies, rather than the verbatim policy?

Kind regards,
Carl







"Nennker, Axel" <Axel.Nennker@xxxxxxxxxxxxx> 
Sent by: higgins-dev-bounces@xxxxxxxxxxx
05/21/2008 07:35 PM
Please respond to
"Higgins \(Trust Framework\) Project developer discussions" 
<higgins-dev@xxxxxxxxxxx>


To
<higgins-dev@xxxxxxxxxxx>
cc

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






I varied the "link"-scheme a littel bit.
http://ignisvulpis.blogspot.com/2008/05/iiw2008a-monday-relmetadata.html

I am sure that IE can handle links and that we could write something the 
could do this in IE for higgins.

I started this for Firefox and the extension now detects the <LINK ...> 
and retrieves the href attribute.
Next step is to download the xrds-metadata and to act on it.
I envision that e.g. the higgins icon changes (e.g. its color) after the 
metadata is retrieved and applicable cards are available.

-Axel

> -----Ursprüngliche Nachricht-----
> Von: higgins-dev-bounces@xxxxxxxxxxx 
> [mailto:higgins-dev-bounces@xxxxxxxxxxx] Im Auftrag von Carl Binding
> Gesendet: Mittwoch, 21. Mai 2008 08:46
> An: Higgins (Trust Framework) Project developer discussions
> Betreff: Re: [higgins-dev] FW: [osis-general] Alternative 
> tohtml 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/s
> treetaddress
> 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
> 
> 
> _______________________________________________
> higgins-dev mailing list
> higgins-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/higgins-dev
> 
_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/higgins-dev




Back to the top