[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [higgins-dev] IMI + OpenID
|
Yes that's what I did now. (see the other email I just sent out).
https://higgins.eclipse.org/cloud-selector-test/We can discuss at IIW whether that's smart or not...
Markus
On Tue, May 12, 2009 at 5:37 PM, John Bradley
<ve7jtb@xxxxxxxxxx> wrote:
In that case the actual token type requested would be encoded in the query string of the token AX identifier.
You still thinking of base64 encoding the object tag to turn it into a query string?
John B.
On 12-May-09, at 10:33 AM, Markus Sabadello wrote:
I was planning to add the object tag in the query string of the token AX identifier. HTTP GETting that object tag from the RP sounds too complicated to me.
I will still do an HTTP GET on the return_to URL in order to get the certificate.
Markus
On Mon, May 11, 2009 at 9:38 PM, John Bradley
<ve7jtb@xxxxxxxxxx> wrote:
The same way that the token type is included in the object tag now.
So for the sake of argument you could do a GET on the page that the user would normally click on with the object tag if it knew where the page was. The OP is the selector.
I don't know what the best format for the info the info is.
One other alternative is to use AX STORE to push a base64 encoded version of the XHTML or object tag. Then the certificate could be retrieved from the post URI.
There are a bunch of options. Making an assumption about the token type an the AX URI is probably not ideal.
John B.
On 11-May-09, at 8:40 PM, Markus Sabadello wrote:
Hmm thanks, but I don't really get that..
I understand the OP needs to do a GET to the RP in order to obtain the RP certificate for encrypting the token.
But how can that GET tell the OP anything about the token type?
Markus
On Mon, May 11, 2009 at 8:28 PM, John Bradley
<ve7jtb@xxxxxxxxxx> wrote:
Markus,
I don't know that I would be that specific about the token type. It could be SAML2.0 or something else.
The actual token type and claims for it need to be retrieved via a GET to the RP so that you have the cert chain.
So I would go with something more generic that indicates to the OP that it needs to do that GET to determine the token to be returned.
John B.
On 11-May-09, at 8:08 PM, Markus Sabadello wrote:
Hi John,
Do you have any intelligent idea for the AX identifiers for
1. requesting the whole token (via AX FETCH)
2. offering a new i-card (via AX STORE)
My idea would be:
1. urn:oasis:names:tc:SAML:1.0:assertion
2. http://schemas.xmlsoap.org/ws/2005/05/identity
Markus
On Fri, May 1, 2009 at 8:44 PM, John Bradley
<ve7jtb@xxxxxxxxxx> wrote:
Markus,
I think that captures it.
The only change I might make is having token be if_available. That will decrease the likelihood a non IMI OP might reject the authen request because it cannot fulfill a required claim.
The IMI OP would prefer the token AX attribute for the reply if the user selects a card that can provide it.
John B.
On 1-May-09, at 8:25 PM, Markus Sabadello wrote:
I tried capturing some thoughts that came up on the last Higgins call, regarding building better IMI support into the OpenID-based "Higgins Web Selector":
http://wiki.eclipse.org/Web_Selector_1.1#Requesting_an_i-card It lists a few possible methods for "doing i-cards" over OpenID:
Method 1: AX attribute identifiers are claim URIs
Method 2a: Well-known AX attribute identifiers are mapped to claim URIs
Method 2b: Well-known SREG attribute identifiers are mapped to claim URIs
Method 3: Advanced IMI compatibility
Markus
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/higgins-dev
_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/higgins-dev
_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/higgins-dev
_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/higgins-dev
_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/higgins-dev
_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/higgins-dev
_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/higgins-dev
_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/higgins-dev
