[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
AW: [higgins-dev] FW: [osis-general] Alternative tohtml object type="application/x-informationCard" ?
|
Problem with plugins in contrast to extension is that plugins are platform dependent.
Mozilla or we would have to build the plugin for all platforms.
Convincing Mozilla to include our plugin into the standard browser might not be easy.
Paul: you have talked to them already?
Having an standard handler for <link rel="xrds.metadata" href="..."> is like a standard handler for <link rel="next" ...>
This is easy and not platform dependent.
Yes, if the plugin were a standard then this would be nice but it is not and the link-metadata stuff has potential to embrace openid and other attribute exchange schemes.
-axel
> -----Ursprüngliche Nachricht-----
> Von: higgins-dev-bounces@xxxxxxxxxxx
> [mailto:higgins-dev-bounces@xxxxxxxxxxx] Im Auftrag von Maxim Kopeyka
> Gesendet: Mittwoch, 21. Mai 2008 20:24
> An: Higgins (Trust Framework) Project developer discussions
> Betreff: Re: [higgins-dev] FW: [osis-general] Alternative
> tohtml object type="application/x-informationCard" ?
>
> Hi,
>
> As for me some Axel's arguments aren't convincing.
> > - HTML-objects are expected to be handled by browser plugins, which
> > are platform dependent.
> Firefox can search an extension for corresponding object's
> type. So any user will know about our extensions (HBX) if he
> gets page with application/x-informationCard object.
> Naturally Mozilla should add our extensions into own
> database. This functionality won't work with <link> tag.
> > - You need javascript kungfu to suppress the "additional
> plugins are needed"
> > message.
> You need plugin registered for corresponding object's type.
> That's not hard to implement it.
>
> I agree with that:
> > 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.
> It's a single advantage.
>
> --
> Regards, Maxim.
>
>
> >
> > -------- Original Message --------
> > Subject: [higgins-dev] FW: [osis-general] Alternative to html
> > object type="application/x-informationCard" ?
> > From: Paul Trevithick <paul@xxxxxxxxxxxxxxxxx>
> > To: 'Higgins (Trust Framework) Project developer discussions'
> > <higgins-dev@xxxxxxxxxxx>
> > Date: 5/21/2008 9:01 AM
> >
> >
> >
> > 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/p
> rivatepersonal
> > 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
>
