Skip to main content

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

One goal of my suggestion is to get rid of the object tag which Mozilla prefers to handle with plugins instead of extensions.

I don't see it as inconvient that LINK is in HEAD.

I want to go to a unified user experience for all/most credential types.
The rendering of the claims/card handling is a task for the client and I want to move away from html forms by the RP (and HTTP basic auth dialogs and choose personal cert dialogs and enter preferred openid forms).

How about a sidebar that opens when cards are applicable?
Then double-click a card or drag a card and claims are transferred (or the identity agent/selector is launched).

-Axel

> -----Ursprüngliche Nachricht-----
> Von: higgins-dev-bounces@xxxxxxxxxxx 
> [mailto:higgins-dev-bounces@xxxxxxxxxxx] Im Auftrag von Carl Binding
> Gesendet: Donnerstag, 22. Mai 2008 08:32
> An: Higgins (Trust Framework) Project developer discussions
> Betreff: 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-relmet
> adata.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
> 
> 
> _______________________________________________
> higgins-dev mailing list
> higgins-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/higgins-dev
> 


Back to the top