[Openid-specs-ab] RP testing
Michael.Jones at microsoft.com
Thu May 14 09:16:09 UTC 2015
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?
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:
To start from the end:
is of course the different endpoints the OP presents (authorization/token/userinfo/..) claims
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
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.
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.
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:
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:
"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
More information about the Openid-specs-ab