Need create request_uri endpoint in AS

[Nat Sakimura]

FAPI Part 2 should have an optional endpoint to create the request object at the AS and gets the request_uri.

[Dave Tonge]

Agreed - this would be a great addition.

[Nat Sakimura]

So, it would be a simple URI at AS to which the client can POST the request object and gets the following back with 200 OK.

200 OK
content-type: application/json

{
    "request_uri":"https:as.example.com/requests/af9dnpqgysEfjslIwwlSq"
}

For errors, we probably need invalid_object. Would that be enough?

[Nat Sakimura]

Dave pointed out that returning expiry time with it would be good.

[Nat Sakimura]

Re: #87 added ros ep. Error needs improvements.

→ <<cset 48a335eb10e7>>

[Nat Sakimura]

I decided to put some other claims like iss and aud and pushed the change to the repo.

Now, I have some additional idea around it. Since we are now pushing the request object to the AS, the AS knows which client certs is to be used for the transaction. Thus, code can actually be bound to the client certs so that all the tokens generated by the AS are actually sender constrained. I will create an additional ticket for this.

[Dave Tonge]

@Nat I've added a pull request to adjust the wording: https://bitbucket.org/openid/fapi/pull-requests/22/improvements-to-request-object-section/diff

I have a question - should we require client authentication like jwsreq:

Server MUST perform Client Authentication to accept the Request Object

[Nat Sakimura]

No, we do not have to have the client authentication to POST the request object. This is because the request object is signed using asymmetric crypto.

If we allow other algorithms, then we need to make it "shall" but since we are not it is not needed.

[Dave Tonge]

OK, sounds good, I think we can close this.