[Openid-specs-ab] RP testing

[Justin Richer]

I really like this approach. It makes it simple for RPs that can handle dynamic discovery (which is a very, very low bar), and it should be clear to developers/testers which test they’re trying to use at a given time.

It also means that each RP test will effectively have a separate issuer, which is a good way to separate things cleanly.

 — Justin


> On Mar 25, 2015, at 6:03 AM, Roland Hedberg <roland.hedberg at umu.se> wrote:
> 
> On to the next challenge :-)
> 
> In order to do RP testing you either need a bunch of OP configured to work in slightly different ways or you need an OP that can change behavior on command.
> 
> I’ve chosen the later path.
> I’ve constructed an OP that can be ’steered’ by crafting the URLs used in a special way.
> 
> The basic format of the path is:
> 
> /<id>/<signalg>/<encalg>/<errtype>/<claims>/<endpoint>
> 
> To start from the end:
> 
> endpoint
> 	is of course the different endpoints the OP presents (authorization/token/userinfo/..)
> claims
> 	is normal/aggregated/distributed
> errtype
> 	this is errors the OP should perform. This is to make certain that the RP actually checks and
> 	understands what it receives. So far I’ve defined these errors:
> 	ath     the at_hash is incorrect
> 	aud     ID Token with invalid aud
> 	ch      the c_hash is incorrect
> 	iat     ID Token without iat claim
> 	idts    the id_token signature is invalid
> 	issi    the id_token iss value is not the same as the provider info issuer
> 	isso    the provider info issuer is not the same as the discovery url
> 	itsub   ID Token without sub claim
> 	kmm     signing/encryption with a key the RP doesn't have access to
> 	nonce   the nonce value returned is not the same as the received
> 	state   the state value returned is not the same as the received
> encalg
> 	The encryption algorithms used, this is actually a tuple. The encryption alg
> 	and the encryption enc algorithms. The tuple are joined by a ':' so a typical
> 	value could be RSA1_5:A128CBC-HS256.
> signalg
> 	Specifies which algorithm that the OP should use for signing JWTs, this algorithm
> 	is use for all signing. So it will for instance be used both for id_token and user
> 	info signing. A typical value would be RSA256.
> id
> 	An identifier of the test run. This together with the IP address of the RP will
> 	be used to construct the filename in which the log of the test seen from the OP’s side
> 	will be stored.
> 
> 
> So if you would want to test rp-idt-iat (Reject ID Token without iat claim) the path of the URL for the
> authorization endpoint could be:
> 
> /rp-idt-iat/_/_/iat/normal/authorization_endpoint
> 
> It’s obvious that testing a RP that does not support dynamic provider configuration will
> be very laborious with the above setup so I’ve worked with the assumption that all the
> RPs to test can read configuration from a .well-known/openid-configuration URL and
> understand it.
> 
> Now, Edmund Jay asked the question whether it would be possible to make it even simpler for the
> RP and just request it to know the test IDs and not construct the whole path.
> And it can be done.
> 
> It would mean that the RP would read for example
> https://example.com/rp-idt-iat/.well-known/openid-configuration and the
> returned provider configuration would contain claims like this:
> 
> {
>  ”authorization_endpoint”: "https://example.com/rp-idt-iat/_/_/iat/normal/authorize",
>  ”token_endpoint”: ”https://example.com/rp-idt-iat/_/_/iat/normal/token”,
>  …
> }
> 
> Questions/comments ?
> 
> - Roland
> 
> "It is the consequence of humanity. We are all formed of frailty and error; let us pardon reciprocally each others’ folly - that is the first law of nature.” - Voltaire
> 
> 
> 
> 
> 
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20150325/15560e87/attachment.asc>