RE: SAML - Re: [foaf-protocols] WebID test suite

its not intended for browsers. Its for soap clients primarily, a type of web user that we are not allowed to really talk about here. And we certainly dont address that communities needs. Its the community of ebook reader say; not a browser, but none the a web user that downloads files, interacts with google, facebook, etc. and otherwise acts like a (non-browser) citizen on the web. The technnique is good classical 20+year old RPC, done the web way. (or not, depending on your politics.) Arguably, all SUN did was reimplement ECMA Remote Operations,  recasting it into XML. But, thats a little unfair... since web services made it to the mainstream (whereas the ASN.1 equivalents from 10 years earlier did not!) client goes to service endpoint, noting it exposes metadata, from which it builds a proxy class on the fly. class indicates the endpoint of an IDP, to which client makes requests for signed assertions, which are returnd to said client. IDP endpoint uses standard interface, for which client normally already has proxy class, with built in serializers and message handlers for the MEPs. Client stuffs token in soap header, and binds header to soap body using a signature. assertion and signature are tied by reference numbers, and key management. Relying party knows that a holder of a particular key was the party that emitted the saml token, where emitter and issuer are distinguished. The use pattern distinguishes itself from bearer tokens, which represent the perceived needs of the browser world - which assumes the browser is untrustworthy (in general). All uses XML (W3C) and xmldsig (W3C), and http (IETF/W3C). And something called WSDL, which competes in the metadata wars. To the point made though, could the SSL channel over which the browser posts the assertion from the IDP be "signed" by that RELAYING channel, using a client cert that the assertion references? to get to the "semantics" of HOK? Yes, but one has to argue why.   
 > From: henry.story@bblfish.net
> Date: Wed, 29 Jun 2011 09:37:03 +0200
> CC: kidehen@openlinksw.com; home_pw@msn.com; public-xg-webid@w3.org
> To: demoss.matt@gmail.com
> Subject: SAML - Re: [foaf-protocols] WebID test suite
> 
> 
> On 29 Jun 2011, at 00:55, Matt DeMoss wrote:
> 
> > Earlier in the thread I half-remembered a SAML profile that seemed to
> > have something in common with WebID.
> > 
> > This is the profile I was remembering:
> > 
> > http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-holder-of-key-browser-sso.html
> 
> Thanks, good find. It looks - on very quick perusal - that the protocol is somewhat different, in that it requires the browser to generate some SAML token, requiring changes to the browsre. But that is a good reference to add to our 
> ISSUE-30.
> 
> Perhaps people with more SAML background can give us deeper insight into this.
> 
> Henry
> 
> 
> > 
> > 
> > 
> > On Tue, Jun 28, 2011 at 6:16 PM, Kingsley Idehen <kidehen@openlinksw.com> wrote:
> >> On 6/28/11 10:39 PM, Peter Williams wrote:
> >>> 
> >>> do use one of the standard assertion formats. Dont make a custom profile
> >>> of it. A good test is that if you use openid or ws-fedp that it works with
> >>> Microsoft ACS as the assertion consuming party. if y ou choose SAML2 (now
> >>> commodity in windows!), ensure it works with ADFS as the assertion consuming
> >>> engine. These products (ACS and ADFS) are "final stage" products, way
> >>> post-research phase, entering the market at the commodization point defined
> >>> as one that maximizes interoperability. if you can inter with them, you
> >>> stand a good change of inteworking with the vast majority of other vendor's
> >>> equivalent implementations.
> >> 
> >> For us middleware types, pragmatic interop is the name of the game. On our
> >> part we'll map whatever exists to WebID in order for it to gain traction :-)
> >> 
> >> We'll take a look at ADFS and SAML2 on Windows re. addition WebID protocol
> >> bridging. Windows isn't foreign territory to us.
> >> 
> >> --
> >> 
> >> Regards,
> >> 
> >> Kingsley Idehen
> >> President&  CEO
> >> OpenLink Software
> >> Web: http://www.openlinksw.com
> >> Weblog: http://www.openlinksw.com/blog/~kidehen
> >> Twitter/Identi.ca: kidehen
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> > 
> 
> Social Web Architect
> http://bblfish.net/
> 
>