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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 >>>> [email protected] >>>> https://dev.eclipse.org/mailman/listinfo/higgins-dev >>>> >>>> >>>> >>>> _______________________________________________ >>>> higgins-dev mailing list >>>> [email protected] >>>> https://dev.eclipse.org/mailman/listinfo/higgins-dev >>>> >>>> >>> _______________________________________________ >>> higgins-dev mailing list >>> [email protected] >>> https://dev.eclipse.org/mailman/listinfo/higgins-dev >>> >>> >>> >>> _______________________________________________ >>> higgins-dev mailing list >>> [email protected] >>> https://dev.eclipse.org/mailman/listinfo/higgins-dev >>> >>> >> _______________________________________________ >> higgins-dev mailing list >> [email protected] >> https://dev.eclipse.org/mailman/listinfo/higgins-dev >> >> >> >> _______________________________________________ >> higgins-dev mailing list >> [email protected] >> https://dev.eclipse.org/mailman/listinfo/higgins-dev >> >> > _______________________________________________ > higgins-dev mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/higgins-dev > > > > _______________________________________________ > higgins-dev mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/higgins-dev > >
_______________________________________________ higgins-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/higgins-dev
