Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[higgins-dev] WG: [osis-general] Alternative to htmlobject type="application/x-informationCard" ?

Forwarded from the osis-general list.
Have fun
Axel

-----Ursprüngliche Nachricht-----
Von: osis-general-bounces@xxxxxxxxxxx [mailto:osis-general-bounces@xxxxxxxxxxx] Im Auftrag von Nennker, Axel
Gesendet: Freitag, 23. Mai 2008 00:00
An: osis-general@xxxxxxxxxxx
Betreff: Re: [osis-general] Alternative to htmlobject type="application/x-informationCard" ?

I posted more related to this here:
http://ignisvulpis.blogspot.com/2008/05/iiw2008a-monday-relmetadata.html

George Fletcher and I talked about this during IIW2008a and now we reached this point:

<link rel="xrds.metadata" href="https://xmldap.org/xmldap.xrds"; />
<!-- NB: httpS The identity agent ensures that the cert is the same or the xrds must be signed -->

The xmldap.xrds looks like: (no signature. Must be served thru SSL) <?xml version=1.0 encoding=UTF-8?> <XRDS xmlns=xri://$xrds>  <XRD xmlns=xri://$XRD*($v*2.0) version=2.0>
  <Type>xri://$xrds*simple</Type>
  <!-- Service specification that identifies the endpoint of the infocard policy for login claims -->
  <Service>
   <Type>http://openinfocard.org/policy/1.0/login</Type>
   <URI>https://xmldap.org/relyingparty/login.xml</URI>
  </Service>
  <!-- Service specification that identifies the endpoint of the infocard policy for registration claims -->
  <Service>
   <Type>http://openinfocard.org/policy/1.0/registration</Type>
   <URI>https://xmldap.org/relyingparty/registration.xml</URI>
  </Service>
   <!-- Service specification that identifies the endpoint of the infocard policy for updating claims at the IdP-->
  <Service>
   <Type>http://openinfocard.org/policy/1.0/update</Type>
   <URI>https://xmldap.org/sts/update.xml</URI>
  </Service>

  <!-- Service specification that identifies the endpoint for submitting login claims -->
  <Service>
   <Type>http://openinfocard.org/service/1.0/login</Type>
   <URI>https://xmldap.org/relyingparty/</URI>
  </Service>
  <!-- Service specification that identifies the endpoint of the infocard policy for login claims -->
  <Service>
   <Type>http://openinfocard.org/service/1.0/registration</Type>
   <URI>https://xmldap.org/relyingparty/registration</URI>
  </Service>
  <!-- 
      Service specification that identifies the endpoint of the infocard policy for updating 
	relationship claims at the IdP
  -->
  <Service>
   <Type>http://openinfocard.org/service/1.0/update</Type>
   <URI>https://xmldap.org/sts/update</URI>
  </Service>
 </XRD>
</XRDS>

Open for discussion but keep it simple. --> avoid WS-Policy

Alles wird gut
Axel


> -----Ursprüngliche Nachricht-----
> Von: Paul Trevithick [mailto:paul@xxxxxxxxxxxxxxxxx]
> Gesendet: Donnerstag, 22. Mai 2008 23:17
> An: Nennker, Axel
> Cc: OSIS General
> Betreff: RE: [osis-general] Alternative to html object 
> type="application/x-informationCard" ?
> 
> Hi Axel,
> 
> Your thoughts here need to be considered. Now that this email has been 
> posted to higgins-dev, let's see what that community says about it.
> 
> -Paul
> 
> > -----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/privatepe
> > rson
> > alidentifier
> > 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/streetadd
> > ress 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
> 
> 

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


Back to the top