RFC 0510 proposal incorrect / missing context?

[TimoGlastra]

The proposal format in RFC 0510 only contains an example with the input_descriptors field. There's no further information on what fields are allowed. The input_descriptors is a field form the presentation Definition, but for it to be a valid presentation definition it needs more fields (such as an id field).

So I'm wondering what should be used here. Just the input_descriptors?

ACA-Py has added an options field that is not documented in the spec: (see https://github.com/hyperledger/aries-cloudagent-python/issues/2082), and it seems AFGO hasn't implemented the proposal message so there's not really an example to go from it seems.

Any other implementations we could look at? I would like to add some context to the RFC, but need to understand it first

[swcurran]

Not much help to offer here. A proposal does not have to be a valid request (e.g. a full definition). For example, for an AnonCreds proposal, the format is a list of attributes and predicates. I’m not sure how valuable/useful that is, but there you go…. Since there is no cryptographic processing to be performed on the proposal — just interpretation and response by the verifier — there is not a requirement that it match a given format (e.g. the PE request). It might be useful to do that, but not required.

I doubt there are other implementations. Since proposal is an Aries concept to enable negotiation, if it is not in other Aries frameworks, it is not likely to be elsewhere.

If options were dropped from the ACA-Py implementation, would the rest of the proposal look like what you are expecting?