Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
I
iotivity-classic
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 3,289
    • Issues 3,289
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Merge Requests 0
    • Merge Requests 0
  • CI / CD
    • CI / CD
    • Pipelines
    • Jobs
    • Schedules
  • Operations
    • Operations
    • Incidents
    • Environments
  • Packages & Registries
    • Packages & Registries
    • Container Registry
  • Analytics
    • Analytics
    • CI / CD
    • Repository
    • Value Stream
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
  • IoTivity
  • iotivity-classic
  • Issues
  • #3

Closed
Open
Opened Jan 31, 2020 by Nathan Heldt-Sheller@Nathan

Update Classic to conform to Gaborone requirements for /roles Updates

The Gaborone requirements are that a Server should reject an update to /roles if: a) the Update is received over an anonymous connection (e.g. CoAP, as opposed to authenticated CoAPS)

  • or - b) the Update contains a public key value that does not match the public key of the currently-authenticated Client

Classic's code appears to conform to these requirements on visual inspection (as of Jan 2020) but Classic still fails the CTT test that would verify this behavior (CT 1.7.4.5). The failure needs to be root-caused, and a fix (possibly simple) applied before OCF can apply these requirements to Fargo and prior Devices (e.g. Classic Devices).

Assignee
Assign to
None
Milestone
None
Assign milestone
Time tracking
None
Due date
None
Reference: iotivity/iotivity-classic#3