[Openid-specs-ab] RP testing

[Mike Jones]

On to the next challenge... :-)

Roland, could you send a note giving people instructions on how to get started on RP testing?  In particular, do you have a list of the RP tests currently implemented and URLs of the RP testing OPs that implement those tests?

				Cheers,
				-- Mike

-----Original Message-----
From: Openid-specs-ab [mailto:openid-specs-ab-bounces at lists.openid.net] On Behalf Of Roland Hedberg
Sent: Wednesday, March 25, 2015 4:03 AM
To: openid-specs-ab at lists.openid.net
Subject: [Openid-specs-ab] RP testing

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