- From: Matt DeMoss <demoss.matt@gmail.com>
- Date: Wed, 29 Jun 2011 15:27:31 -0400
- To: Peter Williams <home_pw@msn.com>
- Cc: "public-xg-webid@w3.org" <public-xg-webid@w3.org>
> its not intended for browsers. Just for clarity I was referencing the "Holder-of-Key Web Browser SSO Profile." It's targeted at a "standard web browser, capable of presenting client certificates in conjunction with a TLS handshake." SAML has a pretty serious marketing problem because I find it difficult to talk sensibly about whether something "supports SAML." On Wed, Jun 29, 2011 at 3:53 AM, Peter Williams <home_pw@msn.com> wrote: > 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/ >> >> >
Received on Wednesday, 29 June 2011 19:27:59 UTC