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
