[Openid-specs-fapi] Name change and FAPI Evolution

[Stuart Low]

I support Baseline and Advanced.

At the potential risk of opening another rabbit hole (sorry again Dave!
:)), I'd also like to suggest consideration for the adoption of semantic
versioning (https://semver.org/) as this is a widely understood
convention for implementer's (ie. software engineering). For published
versions of the standard this would be x.y format (or simply x) while WG
internal changes prior to release could utilise x.y.z. All changes
within a major version (x) would be backward compatible meaning changes
beyond initial .0 would be constrained to MAY, SHOULD, OPTIONAL and
RECOMMENDED clauses or a Brand New Profile (I've used "Extreme" in
examples).

By adopting this through to Certification Suite, tests could be
associated with version numbers (rather than specific references to
clauses) and release notes per version would be used to highlight clause
additions/numbering changes etc. On this basis certification could be
given for "FAPI 1 (Profile)", "FAPI 2 (Profile)" with implementer's
having the choice to potentially further specify certification
indicating they meet "FAPI 2.1 (Profile)".

Prior to considering a ticket creation I'd be interested in the mailing
lists thoughts on this. By way of example this would result in an
initial starting point of:

FAPI 1.0 Read
FAPI 1.0 Read/Write
FAPI 2.0 Baseline
FAPI 2.0 Advanced

As functionality is added (primarily in 2.y I would assume) this would
involve the WG using full x.y.z format then releasing x.y version. From
the current state where there is already a v1 (so it's off limits) the
"typical" initial approach would be to use the arbitrarily non
conformant v0 or v99. Alternatives could be the use of -alpha pre
releases but at least personally I've found this problematic. Since
pictures are often more explanatory here's a rough starting point of how
this would flow. I've deliberately avoided talking about FAPI 3 (ie.
breaking changes post FAPI 2) as this seems like a "Future Stu problem". :)


On 21/2/20 12:30 am, Daniel Fett via Openid-specs-fapi wrote:
> Yes, it should be Baseline.
>
> -Daniel
>
> Am 20.02.20 um 14:19 schrieb n-sakimura:
>> Thanks. That sounds good, though the name that was talked about in
>> the room in the F2F London was “Baseline” instead of “Basic”. 
>>
>> Best, 
>>
>> Nat
>>
>> PLEASE READ:This e-mail is confidential and intended for
>> the named recipient only. If you are not an intended recipient,
>> please notify the sender and delete this e-mail.
>>
>>> 2020/02/19 15:59、Daniel Fett via Openid-specs-fapi
>>> <openid-specs-fapi at lists.openid.net>のメール:
>>>
>>> 
>>> +1
>>>
>>> FWIW, I'm currently preparing a first draft for 2.0. I currently
>>> expect 2.0 to consist of separate documents for the attacker model,
>>> the two profiles, grant management and potentially CIBA.
>>>
>>> -Daniel
>>>
>>> Am 19.02.20 um 16:34 schrieb Dave Tonge via Openid-specs-fapi:
>>>> Dear WG
>>>>
>>>> We had a good discussion on the call today around the next steps
>>>> for FAPI and came to the following conclusion:
>>>>
>>>> 1. We should use versioning to indicate that the FAPI evolution is
>>>> a new major version
>>>> 2. We need to keep support for the current FAPI-R and FAPI-RW for
>>>> some time as they have been implemented by many people and have a
>>>> good suite of conformance tests.
>>>> 3. There were no objections to the names of "Basic" and "Advanced"
>>>>
>>>> With this in mind we propose:
>>>>
>>>> 1. The current "Financial-grade API - Part 1: Read-Only API
>>>> Security Profile" (FAPI Read) spec should be changed to
>>>> "Financial-grade API 1.0 - Part 1: Read-Only API Security Profile
>>>> (FAPI 1.0 Read)
>>>> 2. The current "Financial-grade API - Part 2: Read and Write API
>>>> Security Profile" (FAPI Read/Write) spec should be changed to
>>>> "Financial-grade API 1.0 - Part 2: Read and Write API Security
>>>> Profile (FAPI 1.0 Read/Write)
>>>> 3. We introduce two new documents:
>>>>  - Financial-grade API 2.0 - Basic Security Profile" (FAPI 2.0 Basic)
>>>>  - Financial-grade API 2.0 - Advanced Security Profile" (FAPI 2.0
>>>> Advanced)
>>>>
>>>> This will allow us to maintain the existing specs (and their
>>>> associated conformance suites). It will also allow the evolution of
>>>> FAPI that we've been discussing to move ahead - including with new
>>>> names to signal use-cases beyond financial read and financial
>>>> read/write. The new documents (2.0 Basic and 2.0 Advanced) can be
>>>> re-ordered and won't need to maintain backwards compatibility to
>>>> the numbering of sections and list items.
>>>>
>>>> It would be good to get feedback from the WG about this proposal as
>>>> we are keen to move forward.
>>>>
>>>> Thanks
>>>>
>>>> Dave
>>>>
>>>> -- 
>>>> Dave Tonge
>>>> FAPI Co-Chair
>>>>
>>>>
>>>> _______________________________________________
>>>> Openid-specs-fapi mailing list
>>>> Openid-specs-fapi at lists.openid.net
>>>> http://lists.openid.net/mailman/listinfo/openid-specs-fapi
>>>
>>>
>>> _______________________________________________
>>> Openid-specs-fapi mailing list
>>> Openid-specs-fapi at lists.openid.net
>>> http://lists.openid.net/mailman/listinfo/openid-specs-fapi
>
>
>
> _______________________________________________
> Openid-specs-fapi mailing list
> Openid-specs-fapi at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-fapi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-fapi/attachments/20200221/5136f153/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gmbmndbibhdjdagc.png
Type: image/png
Size: 65460 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-fapi/attachments/20200221/5136f153/attachment-0001.png>