W3C home > Mailing lists > Public > public-xg-webid@w3.org > June 2011

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

From: Matt DeMoss <demoss.matt@gmail.com>
Date: Wed, 29 Jun 2011 15:27:31 -0400
Message-ID: <BANLkTi=m-X2v33i6xMOOXXHguQHKqzjf-Q@mail.gmail.com>
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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:06:24 UTC