RE: RE: Authentication workflow draft.

Hi,

wouldn’t it be possible in case of WS-federation that the STS (when
redirected from the protected resource to the STS) asks the client for a
WebID instead of redirecting the client to the IP? The STS would act as
the Verification Agent for all WS-Federation-oriented protected resources,
creating the token and redirecting the Identification Agent back to the
protected resource.

In this context, we could easily extend WS-Federation with WebID, right?

Cheers
Martin


---------------------------------------------------------------------
Prof. Dr.-Ing. Martin Gaedke
Chemnitz University of Technology
Faculty of Computer Science
Distributed and Self-organizing Computer Systems Group
Straße der Nationen 62
D-09107 Chemnitz
Germany

Phone:    +49 (371) 531-25530
E-Mail:   martin.gaedke@informatik.tu-chemnitz.de
Web Site: http://vsr.informatik.tu-chemnitz.de
XING:     https://www.xing.com/profile/Martin_Gaedke
LinkedIn: http://www.linkedin.com/in/gaedke

For further information on Web Engineering:
* International Society for Web Engineering http://www.iswe-ev.de/
* Int. Conf. on Web Engineering 2011: http://icwe2011.webengineering.org/

* Journal of Web Engineering: http://www.rintonpress.com/journals/jwe/







From: public-xg-webid-request@w3.org
[mailto:public-xg-webid-request@w3.org] On Behalf Of peter williams
Sent: Dienstag, 12. April 2011 21:15
To: 'Akbar Hossain'
Cc: 'WebID XG'
Subject: RE: RE: Authentication workflow draft.

If we wanted to use W3C standards (even partly), we could even post

<wsse: BinarySecurityToken Id="myX509Token"
        ValueType="wsse: X509v3"
        EncodingType="wsse: Base64Binary">
NIFEPzCCA9CrAwIBAgIQEmtJZc0 . .. The rest of the X. 509 base 64 data
FExErTECA .. .
</wsse:BinarySecurityToken>

over https (with client authn + SSL Sessionid).

All it has to be is something like (ignoring the SOAP bit):
http://msdn.microsoft.com/en-us/library/ms996951.aspx (Adding the X.509
Certificate Token to a SOAP Message)

could we be allowed JUST a tiny wee bit of SOAP (since java, and dotNet
and … all do the above, being so ancient a spec)? If not, then we are back
to fussing with mime types and encoding headers etc, per my last message


From: akkiehossain@gmail.com [mailto:akkiehossain@gmail.com] On Behalf Of
Akbar Hossain
Sent: Tuesday, April 12, 2011 11:04 AM
To: peter williams
Cc: WebID XG; Andrei Sambra; Kingsley Idehen
Subject: Re: RE: Authentication workflow draft.

Perhaps a small variant of the delegated service as per foafssl.org
On 12 Apr 2011 18:03, "peter williams" <home_pw@msn.com> wrote:
> Yes, it's time for a restful web service (supported by https client
authn and SSL session management) that takes a base64 encode cert as
input, and returns YES/NO
>
> The input parser should assume the worst: strange CRLF or LR or CR,
random header text, variable number of dashes, missing final EOL, UTF
header bytes, web friendly char sets or ascii - so as to deal with the
realty of "PEM encoding"
>
> Another variant would take a cert sha1 fingerprint, rather than the
cert.
>
> -----Original Message-----
> From: public-xg-webid-request@w3.org
[mailto:public-xg-webid-request@w3.org] On Behalf Of Kingsley Idehen
> Sent: Tuesday, April 12, 2011 9:29 AM
> To: peter williams
> Cc: 'Andrei Sambra'; 'WebID XG'
> Subject: Re: Authentication workflow draft.
>
> On 4/12/11 12:14 PM, peter williams wrote:
>> This is relevant to me, as it means for each URI in the SAN, I do a
uriburner query, which (remotely) looks for a cert:identity match for 1
card at a time.
>>
>> Can sparql have multiple FROM lines? Perhaps?
>
> Yes, re. Virtuoso's SPARQL support.
>
>> Can the query be modified so Id know which URI matched, if one could
specify multiple matches?
>
> Yes.
>
> I am guessing its time for a WebID verification service. Ditto email
verification service as spec'd by Toby a while back.
>
> --
>
> Regards,
>
> Kingsley Idehen
> President& CEO
> OpenLink Software
> Web: http://www.openlinksw.com
> Weblog: http://www.openlinksw.com/blog/~kidehen
> Twitter/Identi.ca: kidehen
>
>
>
>
>
>
>
>

Received on Tuesday, 12 April 2011 19:28:21 UTC